couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Doliner (Commented) (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-1146) Content-Length ignored on GET requests
Date Tue, 10 Apr 2012 02:17:17 GMT


Mark Doliner commented on COUCHDB-1146:

This happens with PUT requests when creating a new database, too. (

And the problem is actually a little worse than originally described...
If the HTTP body arrives in a separate TCP chunk from the headers (as will happen in Nathan's
telnet example) then couchdb will treat the body as invalid data and send a TCP RST to the
client.  If the client hasn't finished reading the previous response yet then it might treat
the RST as an error and bail out.  And yes, it's weird for a client to send a body in a PUT
request when creating a database (I was doing this on accident).

The HTTP/1.1 RFC (2616) says, "a server SHOULD read and forward a message-body on any request"
> Content-Length ignored on GET requests
> --------------------------------------
>                 Key: COUCHDB-1146
>                 URL:
>             Project: CouchDB
>          Issue Type: Bug
>          Components: HTTP Interface
>            Reporter: Nathan Vander Wilt
> In the case of a GET request, CouchDB does not wait for the client to send any content
promised by a Content-Length header but sends its response as soon as the last header is received.
This can confuse some HTTP client libraries (such as node.js) that do not expect to receive
a response before they have finished the request.
> To reproduce:
> $ telnet localhost 5984
> GET / HTTP/1.1
> Content-Length: 3
> ...
> Expected results:
> No response from CouchDB until last "." is typed
> Actual results:
> CouchDB sends response and closes the client's connection as soon as request headers
are done.
> From IRC conversation (and RFC 2616) this doesn't seem to be out-of-spec per se, but
is a bit "rude" and therefore can break fragile clients (e.g.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message