Hi everyone,
This little patch will fix Chrome behavior, which I discovered recently. When you navigate to API page, you will get XML version of API.
This is because Chrome sending 'application/xml' mime type before 'text/html' (which is weird but standard correct). Unfortunately, we are lacking 'q' parameter handling in 'respond_to' plugin to handle this correctly...
--- server/libexec/lib/sinatra/respond_to.rb | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/server/libexec/lib/sinatra/respond_to.rb b/server/libexec/lib/sinatra/respond_to.rb index 8e54bda..a79e099 100644 --- a/server/libexec/lib/sinatra/respond_to.rb +++ b/server/libexec/lib/sinatra/respond_to.rb @@ -237,6 +237,11 @@ module Sinatra def match_accept_type(mime_types, format) selected = [] accepted_types = mime_types.map {|type| Regexp.escape(type).gsub(/\*/,'.*') } + # Fix for Chrome: + if accepted_types.include?('text/html') and accepted_types.include?('application/xml') + accepted_types.delete('text/html') + accepted_types.insert(0, 'text/html') + end accepted_types.each do |at| format.each do |fmt, ht, handler| (selected = [fmt, ht, handler]) and break if ht.match(at)
On 02/22/2010 07:34 AM, mfojtik@redhat.com wrote:
server/libexec/lib/sinatra/respond_to.rb | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/server/libexec/lib/sinatra/respond_to.rb b/server/libexec/lib/sinatra/respond_to.rb index 8e54bda..a79e099 100644 --- a/server/libexec/lib/sinatra/respond_to.rb +++ b/server/libexec/lib/sinatra/respond_to.rb @@ -237,6 +237,11 @@ module Sinatra def match_accept_type(mime_types, format) selected = [] accepted_types = mime_types.map {|type| Regexp.escape(type).gsub(/\*/,'.*') }
# Fix for Chrome:
if accepted_types.include?('text/html') and accepted_types.include?('application/xml')
accepted_types.delete('text/html')
accepted_types.insert(0, 'text/html')
end accepted_types.each do |at| format.each do |fmt, ht, handler| (selected = [fmt, ht, handler]) and break if ht.match(at)
Yeah, I ran into this too. While it is early on, and we aren't guaranteeing backwards-compatibility yet, the cost of doing this is close to zero.
ACK
Please ignore this patch, it will break (/api.xml) functionality in Firefox browser.
On 22/02/10 13:34 +0100, mfojtik@redhat.com wrote:
server/libexec/lib/sinatra/respond_to.rb | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/server/libexec/lib/sinatra/respond_to.rb b/server/libexec/lib/sinatra/respond_to.rb index 8e54bda..a79e099 100644 --- a/server/libexec/lib/sinatra/respond_to.rb +++ b/server/libexec/lib/sinatra/respond_to.rb @@ -237,6 +237,11 @@ module Sinatra def match_accept_type(mime_types, format) selected = [] accepted_types = mime_types.map {|type| Regexp.escape(type).gsub(/\*/,'.*') }
# Fix for Chrome:
if accepted_types.include?('text/html') and accepted_types.include?('application/xml')
accepted_types.delete('text/html')
accepted_types.insert(0, 'text/html')
end accepted_types.each do |at| format.each do |fmt, ht, handler| (selected = [fmt, ht, handler]) and break if ht.match(at)
-- 1.6.6.2
On Mon, 2010-02-22 at 13:34 +0100, mfojtik@redhat.com wrote:
This is because Chrome sending 'application/xml' mime type before 'text/html' (which is weird but standard correct). Unfortunately, we are lacking 'q' parameter handling in 'respond_to' plugin to handle this correctly...
We do .. the rack/accept_media_types gem sorts according to 'q' value. What's the Accept header that Chrome sends ?
David
On 22/02/10 14:34 -0800, David Lutterkort wrote:
On Mon, 2010-02-22 at 13:34 +0100, mfojtik@redhat.com wrote:
This is because Chrome sending 'application/xml' mime type before 'text/html' (which is weird but standard correct). Unfortunately, we are lacking 'q' parameter handling in 'respond_to' plugin to handle this correctly...
We do .. the rack/accept_media_types gem sorts according to 'q' value. What's the Accept header that Chrome sends ?
Sure, rack/accept_media_types handles this properly (IMHO), but in some weird way it doesn't work in Chrome (Chrome sends application/xml always first, either if you request explicitly text/html (by .html).
Chrome headers:
If I request /api, Chrome sends:
"application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5"
If I request /api.xml, Chrome sends:
"application/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5"
On Tue, 2010-02-23 at 13:35 +0100, Michal Fojtik wrote:
On 22/02/10 14:34 -0800, David Lutterkort wrote:
On Mon, 2010-02-22 at 13:34 +0100, mfojtik@redhat.com wrote:
This is because Chrome sending 'application/xml' mime type before 'text/html' (which is weird but standard correct). Unfortunately, we are lacking 'q' parameter handling in 'respond_to' plugin to handle this correctly...
We do .. the rack/accept_media_types gem sorts according to 'q' value. What's the Accept header that Chrome sends ?
Sure, rack/accept_media_types handles this properly (IMHO), but in some weird way it doesn't work in Chrome (Chrome sends application/xml always first, either if you request explicitly text/html (by .html).
You do get HTML though when you request it explicitly, right ?
Chrome headers:
If I request /api, Chrome sends:
"application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5"
If I request /api.xml, Chrome sends:
"application/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5"
Chrome is broken. It prefers application/xml over text/html ? See [1] for a nice rant.
David
[1] http://www.newmediacampaigns.com/page/browser-rest-http-accept-headers
deltacloud-devel@lists.fedorahosted.org