couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
Subject Re: switching between response content type in show? how to trigger html response inst of default xml
Date Sat, 25 Jul 2009 22:22:02 GMT
On Fri, Jul 24, 2009 at 7:06 PM, Adam Jacob<adam@opscode.com> wrote:
> On Fri, Jul 24, 2009 at 2:49 PM, Chris Anderson<jchris@apache.org> 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.

The implementation of respondsWith is built on top of mimeparse.js, my
port of the Mimeparse library. Mimeparse doesn't have a public method
to return all the acceptable matches, it only returns the "best". This
can of course be arbitrary as the protocol allows matches to be equal.

So I'll need to push a change back to the Mimeparse repo to add a
public method to return the supported content-types sorted by quality
score.

Thanks for pushing back Adam. I've even seen situations where browser
accept headers were triggering xml feed generation instead of html.
This isn't fun for new developers, especially as it's triggered by
some browsers and not others.

You've got me thinking about how I can craft an API that makes all
this clearer for users, something like:

respondWith("html", function() { ... }");

respondWith("xml", function() { ... }");

etc...

The difference between this and the current API is that it gets an
ordering for users. So the first matching function would be run to
generate the response. If no functions matched, the first function
would also be run (or maybe there should an option for strict 406
errors.)

Still thinking about all this...


> 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
>



-- 
Chris Anderson
http://jchrisa.net
http://couch.io

Mime
View raw message