From user-return-17966-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Sun Sep 18 14:02:53 2011 Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1379177DF for ; Sun, 18 Sep 2011 14:02:53 +0000 (UTC) Received: (qmail 53681 invoked by uid 500); 18 Sep 2011 14:02:50 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 53648 invoked by uid 500); 18 Sep 2011 14:02:50 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 53639 invoked by uid 99); 18 Sep 2011 14:02:50 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 18 Sep 2011 14:02:50 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=NORMAL_HTTP_TO_IP,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.210.180] (HELO mail-iy0-f180.google.com) (209.85.210.180) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 18 Sep 2011 14:02:44 +0000 Received: by iahk25 with SMTP id k25so6782103iah.11 for ; Sun, 18 Sep 2011 07:02:23 -0700 (PDT) Received: by 10.42.167.2 with SMTP id q2mr2584208icy.162.1316354543629; Sun, 18 Sep 2011 07:02:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.218.69 with HTTP; Sun, 18 Sep 2011 07:01:55 -0700 (PDT) In-Reply-To: References: From: Jason Smith Date: Sun, 18 Sep 2011 21:01:55 +0700 Message-ID: Subject: Re: Empty response for PUT in CouchDB 1.1.0 To: user@couchdb.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org Hi, Jason. I think you might be right. Notice that Dylan's bug triggers around the 1,500 byte mark. That is the typical Ethernet maximum transmission unit. It is likely Dylan's queries are being broken into two packets. Dylan, another thing to do is to identify the exact byte size of a query that triggers this bug. I predict that when you click over to 1,501 bytes it will happen. (The only catch is, that is 1,500 total bytes, including TCP headers and also HTTP headers, so the way to be sure is to use tcpdump or Wireshark). Good luck! On Sun, Sep 18, 2011 at 8:55 PM, Jason Smith wrote: > 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. > > [httpd] > =C2=A0socket_options =3D [{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 couc= hdb. >> The Etag header is appropriately updated to the next revision, and match= es >> 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 num= ber >> 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 heade= rs >> 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 ha= ve >> shortened the content for brevity. Doubt that the data itself matters, b= ut >> 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-6046970607e6f9f39e= e8d9f774c57fb4","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=3Dutf-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-4006347f2e= 64ed9b4e5ce8c3f57e4dfc"} >> >> >> 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 fro= m >> this list, thanks. >> http://mail-archives.apache.org/mod_mbox/couchdb-user/201011.mbox/%3CAAN= LkTimSxUWQhwYfTTGe1vNkhkf2xnMiWmt9eriKMU8P@mail.gmail.com%3E >> http://stackoverflow.com/questions/2503911/getting-an-empty-response-whe= n-calling-couchdb-over-ajax >> >> >> I'm connecting from PHP with a simple PHP Couch client, like: >> private function execute() { >> =C2=A0 =C2=A0 =C2=A0 =C2=A0fwrite($this->sock, $this->getRequest()); >> =C2=A0 =C2=A0 =C2=A0 =C2=A0$response =3D ''; >> =C2=A0 =C2=A0 =C2=A0 =C2=A0while(!feof($this->sock)) { >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0$response .=3D fgets($this->soc= k); >> =C2=A0 =C2=A0 =C2=A0 =C2=A0} >> =C2=A0 =C2=A0 =C2=A0 =C2=A0echo "
REQUEST: {$this->getRequest()}
>> RESPONSE: {$response}
"; //the debug statement outputting my exampl= e >> above >> =C2=A0 =C2=A0 =C2=A0 =C2=A0$this->response =3D new CouchDBResponse($resp= onse); >> =C2=A0 =C2=A0 =C2=A0 =C2=A0return $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 P= UT >> with some logic like: >> $res =3D CouchDB::q("/36e04ac8eb90ca90269c1712510593f0", 'PUT', >> json_encode($doc))->getBody(true); >> if (isset($res->ok) && ($res->ok =3D=3D 1) && ($res->id =3D=3D $doc->_id= ) ) { //ok } >> else { throw new Exception(...); } >> >> So the client thinks the update failed, when in fact it did not. Only th= at >> 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. Additio= nal >> 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 t= o 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=3D1, right? >> >> Also, I have set etc/couchdb/local.ini without luck. >> [couchdb] >> delayed_commits =3D false >> >> >> Thanks for any assistance or ideas. >> >> Cheers, >> Dylan >> > > > > -- > Iris Couch > --=20 Iris Couch