> Right now, if a Rails resource can be represented both in html and > application/xml, rails will return an application/xml representation.
If there are multiple representations with the same q level we take the priority in the order you specify them. e.g. if you have respond_to do |format| format.xml format.html end You get xml, flip the block order around and you get HTML instead. This allows both the client and the server to express their preference where an alpha sorting wouldn't. I'm guessing that you have your xml declarations first. I personally think this is a much better solution than what you're describing here as you get proper content-negotiation rather than just a fancy parser which somehow decides which of the equivalent entries it should consider 'best'. Having said all of that, in my personal opinion the accept header is a horrific idea in practise as there are simply dozens of corner cases where browsers send idiotic values. I've seen IE saying it doesn't support HTML or XML (new tab ie7) various plugins sending completely malformed headers etc. I'm a firm believer that you should pretty much always disable use_accept_header if you'll ever have browsers connecting. But rails supports both paths. -- Cheers Koz -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
