Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of b.candler@pobox.com designates
 208.72.237.25 as permitted sender)
Date: Mon, 2 Feb 2009 09:42:07 +0000
From: Brian Candler <B.Candler@pobox.com>
To: user@couchdb.apache.org
Subject: Default response is text/plain
Message-ID: <20090202094207.GA25494@uk.tiscali.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)

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.