You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Brian Candler <B....@pobox.com> on 2009/02/02 10:42:07 UTC
Default response is text/plain
I was going to post this on JIRA but thought I'd better raise it here first,
in case this is intentional behaviour.
By default, all Couchdb responses have Content-Type: text/plain rather than
application/json - observed using tcpdump on a ruby app using couch-potato,
and easily replicated using telnet.
$ telnet localhost 5984
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /test_suite_db HTTP/1.0
HTTP/1.0 200 OK
Server: CouchDB/0.9.0a739811-incubating (Erlang OTP/R12B)
Date: Mon, 02 Feb 2009 09:31:36 GMT
Content-Type: text/plain;charset=utf-8 <<<<<<<<
Content-Length: 171
Cache-Control: must-revalidate
{"db_name":"test_suite_db","doc_count":1,"doc_del_count":1,"update_seq":7,"purge_seq":0,"compact_running":false,"disk_size":15755,"instance_start_time":"1233566693355400"}Connection closed by foreign host.
However, if you explicitly ask for application/json with an Accept: header,
you get that Content-Type instead.
$ telnet localhost 5984
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /test_suite_db HTTP/1.0
Accept: application/json
HTTP/1.0 200 OK
Server: CouchDB/0.9.0a739811-incubating (Erlang OTP/R12B)
Date: Mon, 02 Feb 2009 09:32:03 GMT
Content-Type: application/json <<<<<<<<
Content-Length: 171
Cache-Control: must-revalidate
{"db_name":"test_suite_db","doc_count":1,"doc_del_count":1,"update_seq":7,"purge_seq":0,"compact_running":false,"disk_size":15755,"instance_start_time":"1233566693355400"}Connection closed by foreign host.
This seems odd behaviour to me. The "negotiated" content is no different,
and the response clearly *is* application/json, whether or not you provide
an Accept: header.
Is this a workaround for some client bug? Or to make Couchdb work better
with browsers for manual interaction?
Now, as it happens: couch-potato/couchrest/rest-client is actually sending
Accept: application/xml
and the response which comes back is
Content-Type: text/plain;charset=utf-8
Of course, the client stack is requesting the wrong media type entirely, but
under this circumstance I'd still expect Couchdb to say that the response is
application/json rather than text/plain, as being a more accurate
description of what has been returned.
So my suggested behaviour would be: only return test/plain if the Accept:
header is present, *and* it contains text/plain, *and* this is higher
priority than application/json (if that is present too). Otherwise return
application/json.
But as I say, maybe this has been discussed before and the current behaviour
is entirely intentional.
Thanks,
Brian.
Re: Default response is text/plain
Posted by Jan Lehnardt <ja...@apache.org>.
Hi Brian,
good digging here, highly appreciated!
I believe we put this in (and there is explicit code
that does it) , so that browsers will render JSON
as text and not offer the result for download.
Cheers
Jan
--
On 2 Feb 2009, at 10:42, Brian Candler wrote:
> I was going to post this on JIRA but thought I'd better raise it
> here first,
> in case this is intentional behaviour.
>
> By default, all Couchdb responses have Content-Type: text/plain
> rather than
> application/json - observed using tcpdump on a ruby app using couch-
> potato,
> and easily replicated using telnet.
>
> $ telnet localhost 5984
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> GET /test_suite_db HTTP/1.0
>
> HTTP/1.0 200 OK
> Server: CouchDB/0.9.0a739811-incubating (Erlang OTP/R12B)
> Date: Mon, 02 Feb 2009 09:31:36 GMT
> Content-Type: text/plain;charset=utf-8 <<<<<<<<
> Content-Length: 171
> Cache-Control: must-revalidate
>
> {"db_name":"test_suite_db","doc_count":1,"doc_del_count":
> 1,"update_seq":7,"purge_seq":0,"compact_running":false,"disk_size":
> 15755,"instance_start_time":"1233566693355400"}Connection closed by
> foreign host.
>
> However, if you explicitly ask for application/json with an Accept:
> header,
> you get that Content-Type instead.
>
> $ telnet localhost 5984
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> GET /test_suite_db HTTP/1.0
> Accept: application/json
>
> HTTP/1.0 200 OK
> Server: CouchDB/0.9.0a739811-incubating (Erlang OTP/R12B)
> Date: Mon, 02 Feb 2009 09:32:03 GMT
> Content-Type: application/json <<<<<<<<
> Content-Length: 171
> Cache-Control: must-revalidate
>
> {"db_name":"test_suite_db","doc_count":1,"doc_del_count":
> 1,"update_seq":7,"purge_seq":0,"compact_running":false,"disk_size":
> 15755,"instance_start_time":"1233566693355400"}Connection closed by
> foreign host.
>
> This seems odd behaviour to me. The "negotiated" content is no
> different,
> and the response clearly *is* application/json, whether or not you
> provide
> an Accept: header.
>
> Is this a workaround for some client bug? Or to make Couchdb work
> better
> with browsers for manual interaction?
>
> Now, as it happens: couch-potato/couchrest/rest-client is actually
> sending
> Accept: application/xml
> and the response which comes back is
> Content-Type: text/plain;charset=utf-8
>
> Of course, the client stack is requesting the wrong media type
> entirely, but
> under this circumstance I'd still expect Couchdb to say that the
> response is
> application/json rather than text/plain, as being a more accurate
> description of what has been returned.
>
> So my suggested behaviour would be: only return test/plain if the
> Accept:
> header is present, *and* it contains text/plain, *and* this is higher
> priority than application/json (if that is present too). Otherwise
> return
> application/json.
>
> But as I say, maybe this has been discussed before and the current
> behaviour
> is entirely intentional.
>
> Thanks,
>
> Brian.
>
Re: Default response is text/plain
Posted by "ara.t.howard" <ar...@gmail.com>.
On Feb 2, 2009, at 9:34 AM, Chris Anderson wrote:
> I prefer being able to look at the responses in the browser, and it's
> not hurting anything. I think the way things are is fine.
>
> (Maybe there's a way to get most browsers to display application/json
> instead of making a file?)
can't work with json without this:
https://addons.mozilla.org/en-US/firefox/addon/8207
let's you open up any doc as text, etc.
a @ http://codeforpeople.com/
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama
Re: Default response is text/plain
Posted by Brian Candler <B....@pobox.com>.
On Mon, Feb 02, 2009 at 08:34:58AM -0800, Chris Anderson wrote:
> On Mon, Feb 2, 2009 at 3:07 AM, Paul Davis <pa...@gmail.com> wrote:
> > Brian,
> >
> > Link Jan say, as far as my recollection goes this was to get browser
> > viewing correct. If you felt like reworking things so that the Accept
> > header were treated more correctly including the weights etc I don't
> > think anyone would argue with more closely supporting the spec.
> >
>
> I prefer being able to look at the responses in the browser, and it's
> not hurting anything. I think the way things are is fine.
>
> (Maybe there's a way to get most browsers to display application/json
> instead of making a file?)
I tried a patch to return application/json unless the UA asked for
text/plain, and got a 'Save as' box in Firefox.
OK, I see the problem. Firefox says
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
but doesn't explicitly accept text/plain or even text/*
I guess for any client for which cares about getting the correct
Content-Type, then it cares enough to provide the right Accept: header.
e.g. for couchrest:
--- lib/couchrest/monkeypatches.rb.orig 2009-02-02 17:24:52.000000000 +0000
+++ lib/couchrest/monkeypatches.rb 2009-02-02 17:25:30.000000000 +0000
@@ -35,4 +35,10 @@
:url => url,
:headers => headers)
end
-end
\ No newline at end of file
+
+ class Request
+ def default_headers
+ { :accept => 'application/json', :accept_encoding => 'gzip, deflate' }
+ end
+ end
+end
Regards,
Brian.
Re: Default response is text/plain
Posted by Jan Lehnardt <ja...@apache.org>.
Looks like we're not the only one discussing this:
http://simonwillison.net/2009/Feb/6/json/
Cheers
Jan
--
On 3 Feb 2009, at 18:02, Jan Lehnardt wrote:
>
> On 3 Feb 2009, at 16:48, Avi Flax wrote:
>
>> On Tue, Feb 3, 2009 at 09:05, Brian Candler <B....@pobox.com>
>> wrote:
>>
>>
>>> How about this patch?
>>>
>>> (Note: I am just an erlang dabbler; there's probably a way to
>>> write this
>>> with less duplication)
>>
>>
>> No worries Brian, I can barely read Erlang. That said, it looks
>> good to me.
>> Kudos for writing a patch! Is there an official channel for
>> submitting it?
>
> That'd be https://issues.apache.org/jira/browse/COUCHDB :)
>
> Cheers
> Jan
> --
>
Re: Default response is text/plain
Posted by Jan Lehnardt <ja...@apache.org>.
On 3 Feb 2009, at 16:48, Avi Flax wrote:
> On Tue, Feb 3, 2009 at 09:05, Brian Candler <B....@pobox.com>
> wrote:
>
>
>> How about this patch?
>>
>> (Note: I am just an erlang dabbler; there's probably a way to write
>> this
>> with less duplication)
>
>
> No worries Brian, I can barely read Erlang. That said, it looks good
> to me.
> Kudos for writing a patch! Is there an official channel for
> submitting it?
That'd be https://issues.apache.org/jira/browse/COUCHDB :)
Cheers
Jan
--
Re: Default response is text/plain
Posted by Avi Flax <av...@arc90.com>.
On Tue, Feb 3, 2009 at 09:05, Brian Candler <B....@pobox.com> wrote:
> How about this patch?
>
> (Note: I am just an erlang dabbler; there's probably a way to write this
> with less duplication)
No worries Brian, I can barely read Erlang. That said, it looks good to me.
Kudos for writing a patch! Is there an official channel for submitting it?
--
Avi Flax » Lead Technologist » Partner » Arc90 » http://arc90.com
Re: Default response is text/plain
Posted by Brian Candler <B....@pobox.com>.
On Mon, Feb 02, 2009 at 01:24:54PM -0500, Avi Flax wrote:
> I think the default content-type should be application/json; that'd be
> more correct. The only time text/plain should be returned is when it's
> specifically asked for. And as a workaround for browsers, we could
> have text/plain be returned if the Accept header contains '*'.
How about this patch?
(Note: I am just an erlang dabbler; there's probably a way to write this
with less duplication)
Regards,
Brian.
Re: Default response is text/plain
Posted by Avi Flax <av...@arc90.com>.
I think the default content-type should be application/json; that'd be
more correct. The only time text/plain should be returned is when it's
specifically asked for. And as a workaround for browsers, we could
have text/plain be returned if the Accept header contains '*'.
--
Avi Flax » Lead Technologist » Partner » Arc90 » http://arc90.com
Re: Default response is text/plain
Posted by Chris Anderson <jc...@apache.org>.
On Mon, Feb 2, 2009 at 3:07 AM, Paul Davis <pa...@gmail.com> wrote:
> Brian,
>
> Link Jan say, as far as my recollection goes this was to get browser
> viewing correct. If you felt like reworking things so that the Accept
> header were treated more correctly including the weights etc I don't
> think anyone would argue with more closely supporting the spec.
>
I prefer being able to look at the responses in the browser, and it's
not hurting anything. I think the way things are is fine.
(Maybe there's a way to get most browsers to display application/json
instead of making a file?)
--
Chris Anderson
http://jchris.mfdz.com
Re: Default response is text/plain
Posted by Paul Davis <pa...@gmail.com>.
Brian,
Link Jan say, as far as my recollection goes this was to get browser
viewing correct. If you felt like reworking things so that the Accept
header were treated more correctly including the weights etc I don't
think anyone would argue with more closely supporting the spec.
HTH,
Paul Davis
On Mon, Feb 2, 2009 at 4:42 AM, Brian Candler <B....@pobox.com> wrote:
> I was going to post this on JIRA but thought I'd better raise it here first,
> in case this is intentional behaviour.
>
> By default, all Couchdb responses have Content-Type: text/plain rather than
> application/json - observed using tcpdump on a ruby app using couch-potato,
> and easily replicated using telnet.
>
> $ telnet localhost 5984
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> GET /test_suite_db HTTP/1.0
>
> HTTP/1.0 200 OK
> Server: CouchDB/0.9.0a739811-incubating (Erlang OTP/R12B)
> Date: Mon, 02 Feb 2009 09:31:36 GMT
> Content-Type: text/plain;charset=utf-8 <<<<<<<<
> Content-Length: 171
> Cache-Control: must-revalidate
>
> {"db_name":"test_suite_db","doc_count":1,"doc_del_count":1,"update_seq":7,"purge_seq":0,"compact_running":false,"disk_size":15755,"instance_start_time":"1233566693355400"}Connection closed by foreign host.
>
> However, if you explicitly ask for application/json with an Accept: header,
> you get that Content-Type instead.
>
> $ telnet localhost 5984
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> GET /test_suite_db HTTP/1.0
> Accept: application/json
>
> HTTP/1.0 200 OK
> Server: CouchDB/0.9.0a739811-incubating (Erlang OTP/R12B)
> Date: Mon, 02 Feb 2009 09:32:03 GMT
> Content-Type: application/json <<<<<<<<
> Content-Length: 171
> Cache-Control: must-revalidate
>
> {"db_name":"test_suite_db","doc_count":1,"doc_del_count":1,"update_seq":7,"purge_seq":0,"compact_running":false,"disk_size":15755,"instance_start_time":"1233566693355400"}Connection closed by foreign host.
>
> This seems odd behaviour to me. The "negotiated" content is no different,
> and the response clearly *is* application/json, whether or not you provide
> an Accept: header.
>
> Is this a workaround for some client bug? Or to make Couchdb work better
> with browsers for manual interaction?
>
> Now, as it happens: couch-potato/couchrest/rest-client is actually sending
> Accept: application/xml
> and the response which comes back is
> Content-Type: text/plain;charset=utf-8
>
> Of course, the client stack is requesting the wrong media type entirely, but
> under this circumstance I'd still expect Couchdb to say that the response is
> application/json rather than text/plain, as being a more accurate
> description of what has been returned.
>
> So my suggested behaviour would be: only return test/plain if the Accept:
> header is present, *and* it contains text/plain, *and* this is higher
> priority than application/json (if that is present too). Otherwise return
> application/json.
>
> But as I say, maybe this has been discussed before and the current behaviour
> is entirely intentional.
>
> Thanks,
>
> Brian.
>