From: Lunar <lunar-L8VBg9NU5dbk1uMJSBkQmQ@public.gmane.org>
To: Rainbows! list <rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org>
Subject: Re: 'Connection reset by peer' when replying before the end of POST data
Date: Wed, 29 Feb 2012 21:57:58 +0100 [thread overview]
Message-ID: <20120229205758.GB10775@candra> (raw)
In-Reply-To: <20120229172315.GA26630-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
Eric Wong wrote:
> Lunar <lunar@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
_______________________________________________
Rainbows! mailing list - rainbows-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying
next prev parent reply other threads:[~2012-02-29 20:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-28 22:15 'Connection reset by peer' when replying before the end of POST data Lunar
2012-02-28 23:39 ` Eric Wong
[not found] ` <20120228233919.GA10168-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2012-02-29 7:22 ` Lunar
2012-02-29 17:23 ` Eric Wong
[not found] ` <20120229172315.GA26630-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2012-02-29 20:57 ` Lunar [this message]
2012-02-29 21:36 ` Eric Wong
[not found] ` <20120229213601.GA7116-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2012-03-02 16:03 ` Lunar
2012-03-02 16:29 ` Lunar
2012-03-02 21:05 ` Eric Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://yhbt.net/rainbows/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120229205758.GB10775@candra \
--to=lunar-l8vbg9nu5dbk1umjsbkqmq@public.gmane.org \
--cc=rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhbt.net/rainbows.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).