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 ambauen@gmail.com designates
 209.85.214.52 as permitted sender)
MIME-Version: 1.0
Sender: ambauen@gmail.com
Date: Sun, 18 Sep 2011 00:13:19 -0700
Message-ID: 
 <CALYgVWsMMnpiU028Xdw9eN78Deqb5m2ZxPh85GgVm94LJu+iDQ@mail.gmail.com>
Subject: Empty response for PUT in CouchDB 1.1.0
From: Dylan Ambauen <dylan@ambauen.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=00151750de3c033e1f04ad31f676

--00151750de3c033e1f04ad31f676
Content-Type: text/plain; charset=ISO-8859-1

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:

REQUEST:
PUT /testdb/36e04ac8eb90ca90269c1712510593f0 HTTP/1.0
Host: 192.168.0.116
Content-Length: 1534
Content-Type: application/json

{"_id":"36e04ac8eb90ca90269c1712510593f0","_rev":"182-6046970607e6f9f39ee8d9f774c57fb4","foo":"bar...."}


RESPONSE:
HTTP/1.0 201 Created
Server: CouchDB/1.1.0 (Erlang OTP/R13B03)
Location: http://192.168.0.116/testdb/36e04ac8eb90ca90269c1712510593f0
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.
http://mail-archives.apache.org/mod_mbox/couchdb-user/201011.mbox/%3CAANLkTimSxUWQhwYfTTGe1vNkhkf2xnMiWmt9eriKMU8P@mail.gmail.com%3E
http://stackoverflow.com/questions/2503911/getting-an-empty-response-when-calling-couchdb-over-ajax


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

--00151750de3c033e1f04ad31f676--