couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <...@iriscouch.com>
Subject Re: Occasional corrupt request
Date Thu, 12 Jan 2012 00:38:09 GMT
Well, anyway, the bug I encountered came about in Git commit 4b0948d
(r979368), the SSL feature. Something about the concomitant Mochiweb
upgrade combined with a reverse-proxy in front of couch triggered it.
Usually HTTP requests arrive in one TCP packet, but the reverse proxy
happened to split it into two, the first with the headers, and a
second with the body. Especially for disallowed queries, couch would
send the 400 and headers immediately. Next, it received the request
body and it would send an RST packet before sending its own response
body. The client gets disconnected before receiving a body, so there
would be errors about content-length and missing bodies

My workaround was to add a delay_send flag in the reverse-proxy, which
more or less allows back-end requests to reconstitute into one packet
before hitting couch.

https://github.com/iriscouch/somdune/commit/a8d98301e669ed6d0846a3c1c049bdaaac70f0a1

Unfortunately, it's not clear if you are having this problem.

On Thu, Jan 12, 2012 at 12:04 AM, Pete Vander Giessen <petevg@gmail.com> wrote:
> Hi Jason,
>
> On Wed, Jan 11, 2012 at 12:55 AM, Jason Smith <jhs@iriscouch.com> wrote:
>> Hi, Pete. Does this error happen only (or mostly) when your request to
>> couch contains a body? Is it impossible to reproduce using CouchDB
>> 1.0? Does it happen most often when attempting a privileged operation
>> which you are not permitted to do? Are you able to run a packet
>> capture like tcpdump and confirm if couch is sending any RST packets
>> to the client?
>
> To answer your questions: Possibly; I haven't tried; I don't believe
> so; I'm having trouble reproducing in my dev environment while running
> useful stuff like tcpdump (the errors tend to come up in embarrassing
> situations like on the CEO's computer while we're demonstrating
> software; I have logs showing the Python tracebacks, but I don't have
> a tcpdump of the problem actually happening.)
>
>> If the answer is "no" then, sorry, I myself haven't seen that yet. My
>> standard tool for this type of problem is tcpdump, FWIW.
>
> tcpdump is definitely good stuff. Now if I can only get the problem to
> show itself while I'm monitoring it ...
>
> Thank you,
>
> ~ PeteVG



-- 
Iris Couch

Mime
View raw message