On Fri, Jul 24, 2009 at 2:49 PM, Chris Anderson wrote:
> Accept header handling in browsers is so bad I'm starting to wish I'd
> never written that code. Kinda want to strip it out altogether.
>
> I believe Rails just stopped supporting the Accept header for the same
> reason. (They've moved to URLs like /path/object.xml due to lack of
> browser support for Accept.)
That is insanity for web services - the Accept header works the way it
does to support negotiation, which is why properly dealing with it is
complicated. Disabling honoring Accept headers is a one way ticket to
crazy town, in my opinion - you can solve this problem by setting
internal options for what content types *you* prefer to return to the
client, all things being equal. In Firefox:
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Means that the application server can choose the content type it
thinks is most suitable at quality 0.9. Because it lists text/xml
first is irrelevant - any of the content types at that quality level
will do. Typically frameworks default to just sending the first thing
they know how to serialize back, but you could just as easily set an
internal preference.
Let the author set the preferred content type if they have multiple
choices - but honor the quality settings. It's not crazy that a web
service client would do:
Accept: application/json,application/xml;q=0.9,text/yaml;q=0.8
Catalyst, the perl web framework, does a great job with this, if you
want something to use as a reference.
> To make a long story short, for the time being you can request:
>
> $CDB/ptest2/_design/vt2/_show/show_details/aacosta?format=html
>
> to override the format.
Or do 'curl -H "Accept: text/html"'
Regards,
Adam
--
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-4759 E: adam@opscode.com