Order of an accept header should not matter to respond_to (Rails 3.0.0.rc)

Thanks for adding the appropriate tags; I wasn't sure which to add.

I don't have a lot of experience with the latest Rails, so take what I have to say with a grain of salt.

While IE's Accept header is a little strange, it is basically equivalent to "/", which is not a ridiculous header to send if your client really can accept most formats.

In this case it is the server's responsibility to choose the preferred format to return to the client. Since format.html is the first in the respond_to block, shouldn't it have higher priority than a format.any catch-all response?

Thanks.

Above, third paragraph should be:

While IE's Accept header is a little strange, it is basically equivalent to "*/*", which is not a ridiculous header to send if your client really can accept most formats.

Markdown stole my *s.

As background, I encountered this bug when attempting to create & view a resource that only had an Atom representation:

def recent
  respond_to do |format|
    format.atom do
      render :content_type => 'application/atom+xml', 
             :text => "invalid atom" and return
    end
  end
end

Which does not work as expected (by displaying an atom feed) with a Firefox Accept header: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8, but instead returns a 406 Not Acceptable. So this bug has potential real world impact.

Hi Rohit,

Here you go; hope I did things right.

Thanks!

A quick read of that blog post reveals:

I am going to assume that in this case HTTP_ACCEPT sent by browser looks really simple like this text/javascript, text/html, text/plain

[...]

So browser is saying that I prefer documents in following order js html plain

This is not correct, as this bug report states. Order does not matter in an accept header, only q values matter in deciding which the client prefers. I don't know if the implementation is effected, but the blog post should probably be corrected.

rails currently does take q value into account.

However if there is no q value specified then what. In that case rails gives preference to the ones specified earlier in the HTTP_ACCEPT value.

Hope that clears your question.

Hi Neeraj,

Of course rails is free to return whatever it wants from the set of possible values supplied by the accept header, if they have equal q values.

But the client has not preferred, in the above example, javascript over html. If rails returns javascript, it is because rails prefers it, not the client.

As an application author I would like to be able to specify in some way that I would rather return HTML than, say, javascript, or the other way round, if the client has not specified a preference. And the order of the accept header does not specify a preference.

In any case, thank you for working on this!

Exactly Erik, I believe this scenario is fixed in Rails master. The blog post explains why and how it is fixed.

Maybe we can start over. I posted a comment on the blog post. Quotations are from the blog post.

For all documents that have same q value give high priority to the one that came first in the list.

An HTTP client does not mean to prioritize mime types by their ordering in the accept header; nothing in the spec says that order matters.

So browser is saying that I prefer documents in following order

js html plain

Again, the client is not saying that it prefers documents in any order; js, html & plain have the same q value; order does not matter.

Now, rails can do whatever it wants with these headers, as long as it honors q values. But order of accept headers is basically random,
and using it to make decisions will, in my opinion, lead to strange errors.

Here is a real world problem with this.

"Accept: /" is treated differently from "Accept: text/xml, text/html" in terms of which respond_to block is used. In other words, if the respond_to block contains:

format.xml { ... } format.html { ... }

If the client uses "Accept: /", the html block will be used. If the client uses
"Accept: text/xml, text/html", the xml block will be used. This would be suprising to the application author, as well as the client.

I know that there are real world problems with bad accept headers being sent by the client, but I don't see how this solution solves those problems.