'Connection reset by peer' when replying before the end of POST data
lunar at anargeek.net
Wed Feb 29 20:57:58 UTC 2012
Eric Wong wrote:
> Lunar <lunar at anargeek.net> wrote:
> > Quoting the "HTTP Connection Management" document  which I mentioned
> > previously: "Servers must therefore close each half of the connection
> > independently."
> > After digging some more at Nginx, it looks like Nginx is doing exactly
> > that. I also looked at Apache and the code responsible for half-closing
> > both side of the connection is very readable. Function is called
> > `ap_lingering_close()` in server/connection.c.
> It's very expensive to do what Apache does with threads+Rainbows!. It
> also appears that Apache and nginx continues to completely drain the
> socket if the client is sending, too (which is your case).
> I don't know if there's a way around draining the socket entirely to
> avoid connection resets in the client :<
With your proposed patch, everything is working as intended. At least, I
can confirm Firefox correctly display the error message sent by the
server and not the less understandable "Connection reset by peer". I can
also confirm that it does not send the complete file: it looks like it
stops sending as soon as either it notices the socket is closed on its
write part, or when the response arrives. I am satisfied enough not to
dive in libxpcom…
> You could emulate lingering close with something like this:
> (valid for ThreadSpawn/ThreadPool, not EM/Cool.io stuff)
> diff --git a/lib/rainbows/client.rb b/lib/rainbows/client.rb
> index b456eca..9d8256a 100644
> --- a/lib/rainbows/client.rb
> +++ b/lib/rainbows/client.rb
> @@ -6,4 +6,16 @@ class Rainbows::Client < Kgio::Socket
> include Rainbows::ProcessClient
> alias write kgio_write
> + def close
> + close_write
> + buf = ""
> + begin
> + kgio_wait_readable(2)
> + buf = kgio_tryread(512, buf)
> + rescue
> + break
> + end while buf
> + super
> + end
> I'm not going to apply that to Rainbows!, it's needless
> overhead/complexity for dealing with clients I want to reject
> anyways (and you're still draining the client socket).
That was exactly what I was looking for. It even works fine on Ruby
1.8.7. I can include that code directly in Coquelicot (by reopening
Rainbows::Client to add this extra method) so my pet case is solved.
I could see it part of Rainbows!, as optional behaviour, off by default
if you'd prefer, but I am fine either way.
Thanks for your help! I will let you know as soon as enhanced Coquelicot
codebase using Rainbows! is clean enough for a wider exposure (and I
have been noticed that the public repository is now back).
More information about the rainbows-talk