'Connection reset by peer' when replying before the end of POST data

[Lunar]

Eric Wong wrote:
> Lunar <lunar at anargeek.net> wrote:
> > Quoting the "HTTP Connection Management" document [1] 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
>  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).

Cheers,
-- 
Lunar