couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <>
Subject Re: Empty response for PUT in CouchDB 1.1.0
Date Sun, 18 Sep 2011 13:55:18 GMT
Hi, Dylan. Are you able to Build CouchDB from Git or Subversion?

If you can confirm whether the change occurs at commit 4b0948d (or
Subversion r979368) that would be a major clue.

In addition (or alternatively) are you able to run tcpdump on the
CouchDB machine? Could you confirm whether it is sending RST packets
after its response headers?

I struggled with a similar symptom but was unable to identify the root
cause. I confirmed that the bug was introduced in that commit (SSL
support) and in particular, the Mochiweb upgrade. In my case, if an
unauthorized request was split into two TCP packets (a packet with
headers and a PSH flag, then a packet with the body), I would get the
same response.

Finally, does adding delay_send to the socket options helps at all? It
is in the config.

  socket_options = [{delay_send, true}]

That was my final workaround; but I feel like Shatner on the airplane
and I still wonder whether the bug will kill us all yet.

(If none of these tests change your couch behavior then we probably
have different bugs after all.)

On Sun, Sep 18, 2011 at 2:13 PM, Dylan Ambauen <> wrote:
> I'm getting an empty response body to a PUT request with CouchDB 1.1.0.
> This is unexpected behavior.
> Response headers are properly formatted.
> The response is 201 Created, which usually means the operation completed
> successfully.
> The PUT operation does complete, all of the data is written back to couchdb.
> The Etag header is appropriately updated to the next revision, and matches
> what is actually saved to couch.
> Content-length is set to 97, but the response itself is empty.
> Response body is blank.
> Now, for the inconsistent part. The empty response only occurs when the
> document being PUT gets big. The issue does not seem to correlate to number
> of updates to the doc, but rather size of the doc being updated. When I
> update a doc of size 1206 bytes (which is not that big!), I get an
> appropriate response. When I update a doc of 1310 bytes, I get an empty
> response. 1206 and 1310 specifically are sample values from my tests to
> isolate the problem. Those byte counts are included in the request headers
> as content length. It is the string length of the doc I am attempting to
> write. In my example below, the request content length is 1534, but i have
> shortened the content for brevity. Doubt that the data itself matters, but
> maybe 10 simple string fields of <100 bytes and a few fields containing
> arrays or hashes, with < 100 items, etc. Nothing fancy, Couch should be able
> to handle this.
> For example:
> PUT /testdb/36e04ac8eb90ca90269c1712510593f0 HTTP/1.0
> Host:
> Content-Length: 1534
> Content-Type: application/json
> {"_id":"36e04ac8eb90ca90269c1712510593f0","_rev":"182-6046970607e6f9f39ee8d9f774c57fb4","foo":"bar...."}
> HTTP/1.0 201 Created
> Server: CouchDB/1.1.0 (Erlang OTP/R13B03)
> Location:
> Etag: "183-4006347f2e64ed9b4e5ce8c3f57e4dfc"
> Date: Sat, 17 Sep 2011 20:04:26 GMT
> Content-Type: text/plain;charset=utf-8
> Content-Length: 97
> Cache-Control: must-revalidate
> (the body of the response is empty, this is the error condition. nothing.)
> Whereas, we would expect to see a response like:
> {"ok":true,"id":"36e04ac8eb90ca90269c1712510593f0","rev":"183-4006347f2e64ed9b4e5ce8c3f57e4dfc"}
> The only two links I've found so far are below, but both were solved by some
> javascript client settings. I'm not using a js client. First link is from
> this list, thanks.
> I'm connecting from PHP with a simple PHP Couch client, like:
> private function execute() {
>        fwrite($this->sock, $this->getRequest());
>        $response = '';
>        while(!feof($this->sock)) {
>            $response .= fgets($this->sock);
>        }
>        echo "<pre>REQUEST: {$this->getRequest()}
> RESPONSE: {$response}</pre>"; //the debug statement outputting my example
> above
>        $this->response = new CouchDBResponse($response);
>        return $this->response;
> }
> I recently upgraded from CouchDB 0.8.0 to 1.1.0, my client did not have any
> problems with 0.8.0. It is a problem now because without a response body,
> the client thinks the PUT failed. Normally we would want to validate a PUT
> with some logic like:
> $res = CouchDB::q("/36e04ac8eb90ca90269c1712510593f0", 'PUT',
> json_encode($doc))->getBody(true);
> if (isset($res->ok) && ($res->ok == 1) && ($res->id == $doc->_id)
) { //ok }
> else { throw new Exception(...); }
> So the client thinks the update failed, when in fact it did not. Only that
> Couch failed to send back a properly formatted response. Client copy of the
> doc is now out of rev sync with the server, and the client dies. Additional
> updates to the client side doc are lost as later writebacks are rejected
> without the correct _rev.
> Suppose I could inspect the Etag header of the response, which appears to be
> accurate. However, also seems like a hack that shouldnt be necessary.
> Furthermore, I cant find any documentation that it is ok to rely upon an
> Etag header when the response body is empty. Thats the point of awaiting a
> response with ok=1, right?
> Also, I have set etc/couchdb/local.ini without luck.
> [couchdb]
> delayed_commits = false
> Thanks for any assistance or ideas.
> Cheers,
> Dylan

Iris Couch

View raw message