From normalperson at yhbt.net  Fri Nov 12 19:29:17 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Fri, 12 Nov 2010 16:29:17 -0800
Subject: upcoming env['rack.input'] improvements
Message-ID: <20101113002917.GA8065@dcvr.yhbt.net>

Hello all,

The next versions of Unicorn and Rainbows! will support intentionally
violating the Rack 1.x spec and allowing non-rewindable input bodies
by setting:

  rewindable_input false

  (config directive name not finalized, feedback appreciated)

in the Unicorn/Rainbows! config file.  This will allow applications to
handle larger, streamed requests without worrying about disk/memory
usage at all.  For Rack 1.x conformance, this rewindable_input directive
true by default (but will probably be off with Rack 2.x).

Rainbows! will also support HTTP/1.1 keepalive for requests with a body,
but only if the body (and trailers) are fully consumed by the
application.

The implementation of Unicorn::TeeInput is also simplified and based on
Unicorn::StreamInput.  However there is one minor regression to TeeInput
made in the interest of simplicity that will not noticeable to most
users: calling env['rack.input'].rewind causes the entire request to be
buffered if any data has previously been read off env['rack.input'].


Evented concurrency options (e.g: :Rev and :EventMachine) continue to
buffer the entire body in the existing way, and are unaffected by any
of these changes (except keepalive will always function).

-- 
Eric Wong

From normalperson at yhbt.net  Mon Nov 15 13:41:02 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Mon, 15 Nov 2010 10:41:02 -0800
Subject: [ANN] kgio library / RubyGem
In-Reply-To: <20100928030302.GA3452@dcvr.yhbt.net>
References: <20100928030302.GA3452@dcvr.yhbt.net>
Message-ID: <20101115184102.GB765@dcvr.yhbt.net>

Eric Wong <normalperson at yhbt.net> wrote:
> Hello all,
> 
> I've released kgio, a kinder, gentler I/O library for Ruby.  Some of its
> features are useful for Unicorn, and all of it is useful for Rainbows!

OK, it's got a separate mailing list at kgio at librelist.com, now.

Apparently it's garnered some attention and dalli[1] is one of the first
projects to start using it.

Homepage and git repository locations remain the same:

	http://unicorn.bogomips.org/kgio/
	git://git.bogomips.org/kgio.git
	http://git.bogomips.org/cgit/kgio.git

[1] - git://github.com/mperham/dalli

-- 
Eric Wong

From normalperson at yhbt.net  Fri Nov 19 22:33:25 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Sat, 20 Nov 2010 03:33:25 +0000
Subject: [ANN] Rainbows! 2.0.0 - minority rules!
Message-ID: <20101120033325.GB22030@dcvr.yhbt.net>

Changes:

This release is targeted at the minority of web applications
that deal heavily with uploads.

Thanks to Unicorn 3.x, we now support HTTP keepalive for
requests with bodies as long as the application consumes them.
Unicorn 3.x also allows disabling the rewindability requirement
of "rack.input" (in violation of the Rack 1.x spec).

The global client_body_max_size may also be applied per-endpoint
using the Rainbows::MaxBody middleware described in:

  http://rainbows.rubyforge.org/Rainbows/MaxBody.html

* http://rainbows.rubyforge.org/
* rainbows-talk at rubyforge.org
* git://git.bogomips.org/rainbows.git

-- 
Eric Wong

From normalperson at yhbt.net  Fri Nov 19 22:39:54 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Sat, 20 Nov 2010 03:39:54 +0000
Subject: [ANN] Zbatery 0.5.0 - fork-free HTTP serving
In-Reply-To: <20101120033325.GB22030@dcvr.yhbt.net>
References: <20101120033325.GB22030@dcvr.yhbt.net>
Message-ID: <20101120033954.GA26664@dcvr.yhbt.net>

Changes:

This release syncs up with the latest from Rainbows! 2.0.x
and Unicorn 3.0.x.  See Rainbows! and Unicorn release notes
and changelogs for relevant details.

* http://zbatery.bogomip.org/
* rainbows-talk at rubyforge.org
* git://git.bogomips.org/zbatery.git

-- 
Eric Wong

From jakecdouglas at gmail.com  Wed Nov 24 15:38:36 2010
From: jakecdouglas at gmail.com (Jake Douglas)
Date: Wed, 24 Nov 2010 12:38:36 -0800
Subject: Zbatery/Rainbows keepalive problem?
Message-ID: <AANLkTimSuK7-ihgCa00D-fot4U-FbZt2diQFndyN4uit@mail.gmail.com>

I am using zbatery with ThreadPool and just upgraded to 0.5.0, which
subsequently upgraded rainbows to 2.0.0 and unicorn to 3.0.0. My
browser(s) now hangs for a while during each request. I noticed some
discussion about keep alive in the changelog. Putting
"keepalive_timeout 0" in the rainbows configuration fixes it. Am I
doing something wrong or is this a bug?

Thanks


-- 
Jake Douglas
206-795-9207

From normalperson at yhbt.net  Wed Nov 24 16:17:15 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Wed, 24 Nov 2010 21:17:15 +0000
Subject: Zbatery/Rainbows keepalive problem?
In-Reply-To: <AANLkTimSuK7-ihgCa00D-fot4U-FbZt2diQFndyN4uit@mail.gmail.com>
References: <AANLkTimSuK7-ihgCa00D-fot4U-FbZt2diQFndyN4uit@mail.gmail.com>
Message-ID: <20101124211714.GA25256@dcvr.yhbt.net>

Jake Douglas <jakecdouglas at gmail.com> wrote:
> I am using zbatery with ThreadPool and just upgraded to 0.5.0, which
> subsequently upgraded rainbows to 2.0.0 and unicorn to 3.0.0. My
> browser(s) now hangs for a while during each request. I noticed some
> discussion about keep alive in the changelog. Putting
> "keepalive_timeout 0" in the rainbows configuration fixes it. Am I
> doing something wrong or is this a bug?

Are you setting a Content-Length or Transfer-Encoding in your app?

You can add Rack::Chunked and Rack::ContentLength middlewares to your
config (some frameworks like Rails already do this, I think).

Which versions of Zbatery/Rainbows!/Unicorn were you using before which
exhibited this?  Rainbows!/Zbatery has supported keepalive for some time
and none of the three servers ever included
Rack::Chunked/Rack::ContentLength in its middleware stack by default.

-- 
Eric Wong

From jakecdouglas at gmail.com  Wed Nov 24 16:29:28 2010
From: jakecdouglas at gmail.com (Jake Douglas)
Date: Wed, 24 Nov 2010 13:29:28 -0800
Subject: Zbatery/Rainbows keepalive problem?
In-Reply-To: <20101124211714.GA25256@dcvr.yhbt.net>
References: <AANLkTimSuK7-ihgCa00D-fot4U-FbZt2diQFndyN4uit@mail.gmail.com>
	<20101124211714.GA25256@dcvr.yhbt.net>
Message-ID: <AANLkTi=oKL0Saw9sjf8Lrw-JakmOUKHnM363Qw=6JQO8@mail.gmail.com>

I was using zbatery 0.4.0, Unicorn 2.0.1, unsure of the rainbows
version. This is a Rails 3.0.3 app and I am not setting any headers
myself. Are you saying that Rails is doing something that is causing
the problem? Please bear with me, as I am not familiar with the
details of how keep alive works.

Thanks

On Wed, Nov 24, 2010 at 1:17 PM, Eric Wong <normalperson at yhbt.net> wrote:
> Jake Douglas <jakecdouglas at gmail.com> wrote:
>> I am using zbatery with ThreadPool and just upgraded to 0.5.0, which
>> subsequently upgraded rainbows to 2.0.0 and unicorn to 3.0.0. My
>> browser(s) now hangs for a while during each request. I noticed some
>> discussion about keep alive in the changelog. Putting
>> "keepalive_timeout 0" in the rainbows configuration fixes it. Am I
>> doing something wrong or is this a bug?
>
> Are you setting a Content-Length or Transfer-Encoding in your app?
>
> You can add Rack::Chunked and Rack::ContentLength middlewares to your
> config (some frameworks like Rails already do this, I think).
>
> Which versions of Zbatery/Rainbows!/Unicorn were you using before which
> exhibited this? ?Rainbows!/Zbatery has supported keepalive for some time
> and none of the three servers ever included
> Rack::Chunked/Rack::ContentLength in its middleware stack by default.
>
> --
> Eric Wong
> _______________________________________________
> Rainbows! mailing list - rainbows-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rainbows-talk
> Do not quote signatures (like this one) or top post when replying
>



-- 
Jake Douglas
206-795-9207

From normalperson at yhbt.net  Wed Nov 24 17:14:02 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Wed, 24 Nov 2010 14:14:02 -0800
Subject: Zbatery/Rainbows keepalive problem?
In-Reply-To: <AANLkTi=oKL0Saw9sjf8Lrw-JakmOUKHnM363Qw=6JQO8@mail.gmail.com>
References: <AANLkTimSuK7-ihgCa00D-fot4U-FbZt2diQFndyN4uit@mail.gmail.com>
	<20101124211714.GA25256@dcvr.yhbt.net>
	<AANLkTi=oKL0Saw9sjf8Lrw-JakmOUKHnM363Qw=6JQO8@mail.gmail.com>
Message-ID: <20101124221402.GA28625@dcvr.yhbt.net>

Jake Douglas <jakecdouglas at gmail.com> wrote:
> On Wed, Nov 24, 2010 at 1:17 PM, Eric Wong <normalperson at yhbt.net> wrote:
> > Jake Douglas <jakecdouglas at gmail.com> wrote:
> >> I am using zbatery with ThreadPool and just upgraded to 0.5.0, which
> >> subsequently upgraded rainbows to 2.0.0 and unicorn to 3.0.0. My
> >> browser(s) now hangs for a while during each request. I noticed some
> >
> > Are you setting a Content-Length or Transfer-Encoding in your app?
> >
> > You can add Rack::Chunked and Rack::ContentLength middlewares to your
> > config (some frameworks like Rails already do this, I think).
> >
> > Which versions of Zbatery/Rainbows!/Unicorn were you using before which
> > exhibited this? ?Rainbows!/Zbatery has supported keepalive for some time
> > and none of the three servers ever included
> > Rack::Chunked/Rack::ContentLength in its middleware stack by default.
>
> I was using zbatery 0.4.0, Unicorn 2.0.1, unsure of the rainbows
> version. This is a Rails 3.0.3 app and I am not setting any headers
> myself. Are you saying that Rails is doing something that is causing
> the problem? Please bear with me, as I am not familiar with the
> details of how keep alive works.

<top posting corrected>

Responses without keepalive don't need additional headers since the
server just closes the connection to notify the client.

HTTP/1.1 with keepalive requires a Content-Length (or Transfer-Encoding:
chunked) header to determine response boundaries, otherwise clients
would never know when one response ends and another begins.

The normal Rails "render" path already seems[1] to add Content-Length;
are you doing something else to send responses from Rails?

Including the Rack::Chunked/Rack::ContentLength middlewares (at the top
of the middleware stack) should solve all your problems.

If you only serve HTTP/1.1, you can probably get away with only
Rack::Chunked...


[1] - I haven't had a chance to test this myself

-- 
Eric Wong

From jakecdouglas at gmail.com  Fri Nov 26 23:35:16 2010
From: jakecdouglas at gmail.com (Jake Douglas)
Date: Fri, 26 Nov 2010 20:35:16 -0800
Subject: Zbatery/Rainbows keepalive problem?
In-Reply-To: <20101124221402.GA28625@dcvr.yhbt.net>
References: <AANLkTimSuK7-ihgCa00D-fot4U-FbZt2diQFndyN4uit@mail.gmail.com>
	<20101124211714.GA25256@dcvr.yhbt.net>
	<AANLkTi=oKL0Saw9sjf8Lrw-JakmOUKHnM363Qw=6JQO8@mail.gmail.com>
	<20101124221402.GA28625@dcvr.yhbt.net>
Message-ID: <AANLkTi=J9cXKj+7Wi5AbL6FvwsqdJeb9UH6e-Yfs05v-@mail.gmail.com>

On Wed, Nov 24, 2010 at 2:14 PM, Eric Wong <normalperson at yhbt.net> wrote:
> Jake Douglas <jakecdouglas at gmail.com> wrote:
>> On Wed, Nov 24, 2010 at 1:17 PM, Eric Wong <normalperson at yhbt.net> wrote:
>> > Jake Douglas <jakecdouglas at gmail.com> wrote:
>> >> I am using zbatery with ThreadPool and just upgraded to 0.5.0, which
>> >> subsequently upgraded rainbows to 2.0.0 and unicorn to 3.0.0. My
>> >> browser(s) now hangs for a while during each request. I noticed some
>> >
>> > Are you setting a Content-Length or Transfer-Encoding in your app?
>> >
>> > You can add Rack::Chunked and Rack::ContentLength middlewares to your
>> > config (some frameworks like Rails already do this, I think).
>> >
>> > Which versions of Zbatery/Rainbows!/Unicorn were you using before which
>> > exhibited this? ?Rainbows!/Zbatery has supported keepalive for some time
>> > and none of the three servers ever included
>> > Rack::Chunked/Rack::ContentLength in its middleware stack by default.
>>
>> I was using zbatery 0.4.0, Unicorn 2.0.1, unsure of the rainbows
>> version. This is a Rails 3.0.3 app and I am not setting any headers
>> myself. Are you saying that Rails is doing something that is causing
>> the problem? Please bear with me, as I am not familiar with the
>> details of how keep alive works.
>
> <top posting corrected>
>
> Responses without keepalive don't need additional headers since the
> server just closes the connection to notify the client.
>
> HTTP/1.1 with keepalive requires a Content-Length (or Transfer-Encoding:
> chunked) header to determine response boundaries, otherwise clients
> would never know when one response ends and another begins.
>
> The normal Rails "render" path already seems[1] to add Content-Length;
> are you doing something else to send responses from Rails?
>
> Including the Rack::Chunked/Rack::ContentLength middlewares (at the top
> of the middleware stack) should solve all your problems.
>
> If you only serve HTTP/1.1, you can probably get away with only
> Rack::Chunked...
>
>
> [1] - I haven't had a chance to test this myself
>
> --
> Eric Wong


I am not doing anything special to send responses from Rails, only 'render'.

I can see in my browser that keep-alive is set, and Content-Length is
also set. It looks like the first couple requests finish quickly, and
then the remaining take an additional 5 seconds each. It seems the
browser is hanging for the default keep-alive timeout of 5 seconds on
each request before proceeding. This happens with different browsers.

Is there additional information I can provide to give better insight
into why this is happening?

Thanks

From normalperson at yhbt.net  Sat Nov 27 03:50:11 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Sat, 27 Nov 2010 00:50:11 -0800
Subject: Zbatery/Rainbows keepalive problem?
In-Reply-To: <AANLkTi=J9cXKj+7Wi5AbL6FvwsqdJeb9UH6e-Yfs05v-@mail.gmail.com>
References: <AANLkTimSuK7-ihgCa00D-fot4U-FbZt2diQFndyN4uit@mail.gmail.com>
	<20101124211714.GA25256@dcvr.yhbt.net>
	<AANLkTi=oKL0Saw9sjf8Lrw-JakmOUKHnM363Qw=6JQO8@mail.gmail.com>
	<20101124221402.GA28625@dcvr.yhbt.net>
	<AANLkTi=J9cXKj+7Wi5AbL6FvwsqdJeb9UH6e-Yfs05v-@mail.gmail.com>
Message-ID: <20101127085011.GA8663@dcvr.yhbt.net>

Jake Douglas <jakecdouglas at gmail.com> wrote:
> On Wed, Nov 24, 2010 at 2:14 PM, Eric Wong <normalperson at yhbt.net> wrote:
> >
> > The normal Rails "render" path already seems[1] to add Content-Length;
> > are you doing something else to send responses from Rails?
> 
> I am not doing anything special to send responses from Rails, only 'render'.
> 
> I can see in my browser that keep-alive is set, and Content-Length is
> also set. It looks like the first couple requests finish quickly, and
> then the remaining take an additional 5 seconds each. It seems the
> browser is hanging for the default keep-alive timeout of 5 seconds on
> each request before proceeding. This happens with different browsers.

Interesting.  I rarely actually do anything with a full web browser,
but I can confirm keepalive works as expected with curl...  Is there
anything in your error logs such as exceptions being thrown by your
app?

Can anybody else reproduce this behavior Jake is seeing?

> Is there additional information I can provide to give better insight
> into why this is happening?

tcpdump or similar output would be useful, thanks!

-- 
Eric Wong

From jakecdouglas at gmail.com  Sat Nov 27 16:55:34 2010
From: jakecdouglas at gmail.com (Jake Douglas)
Date: Sat, 27 Nov 2010 13:55:34 -0800
Subject: Zbatery/Rainbows keepalive problem?
In-Reply-To: <20101127085011.GA8663@dcvr.yhbt.net>
References: <AANLkTimSuK7-ihgCa00D-fot4U-FbZt2diQFndyN4uit@mail.gmail.com>
	<20101124211714.GA25256@dcvr.yhbt.net>
	<AANLkTi=oKL0Saw9sjf8Lrw-JakmOUKHnM363Qw=6JQO8@mail.gmail.com>
	<20101124221402.GA28625@dcvr.yhbt.net>
	<AANLkTi=J9cXKj+7Wi5AbL6FvwsqdJeb9UH6e-Yfs05v-@mail.gmail.com>
	<20101127085011.GA8663@dcvr.yhbt.net>
Message-ID: <AANLkTimkvFSjiz60Bm90NQUa0+7-UE7-R35nVwU8LcQi@mail.gmail.com>

On Sat, Nov 27, 2010 at 12:50 AM, Eric Wong <normalperson at yhbt.net> wrote:
> Jake Douglas <jakecdouglas at gmail.com> wrote:
>> On Wed, Nov 24, 2010 at 2:14 PM, Eric Wong <normalperson at yhbt.net> wrote:
>> >
>> > The normal Rails "render" path already seems[1] to add Content-Length;
>> > are you doing something else to send responses from Rails?
>>
>> I am not doing anything special to send responses from Rails, only 'render'.
>>
>> I can see in my browser that keep-alive is set, and Content-Length is
>> also set. It looks like the first couple requests finish quickly, and
>> then the remaining take an additional 5 seconds each. It seems the
>> browser is hanging for the default keep-alive timeout of 5 seconds on
>> each request before proceeding. This happens with different browsers.
>
> Interesting. ?I rarely actually do anything with a full web browser,
> but I can confirm keepalive works as expected with curl... ?Is there
> anything in your error logs such as exceptions being thrown by your
> app?
>
> Can anybody else reproduce this behavior Jake is seeing?
>
>> Is there additional information I can provide to give better insight
>> into why this is happening?
>
> tcpdump or similar output would be useful, thanks!
>
> --
> Eric Wong
> _______________________________________________
> Rainbows! mailing list - rainbows-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rainbows-talk
> Do not quote signatures (like this one) or top post when replying
>


It looks like the first issue is that by default Rails does not
actually use Rack::ContentLength or set the Content-Length itself.

The next issue is this bug, where Rack::ContentLength has some
conditions that cause it to skip handling of the
ActionDispatch::Response object from Rails. (ActionDispatch::Response
< Rack::Response)
http://rack.lighthouseapp.com/projects/22435/tickets/95-responsefinish-and-contentlength

Fixing and enabling Rack::ContentLength seems to fix the issue for a
single request to Rails from curl, but I am still getting the problem
in my browser(s). Zbatery logs say that the request finishes quickly
but the browser hangs for 5 seconds at a time. It is unclear to me
what the cause is. I will try to do some more research and let you
know the result.

Thanks

From jakecdouglas at gmail.com  Sun Nov 28 00:30:18 2010
From: jakecdouglas at gmail.com (Jake Douglas)
Date: Sat, 27 Nov 2010 21:30:18 -0800
Subject: Zbatery/Rainbows keepalive problem?
In-Reply-To: <AANLkTimkvFSjiz60Bm90NQUa0+7-UE7-R35nVwU8LcQi@mail.gmail.com>
References: <AANLkTimSuK7-ihgCa00D-fot4U-FbZt2diQFndyN4uit@mail.gmail.com>
	<20101124211714.GA25256@dcvr.yhbt.net>
	<AANLkTi=oKL0Saw9sjf8Lrw-JakmOUKHnM363Qw=6JQO8@mail.gmail.com>
	<20101124221402.GA28625@dcvr.yhbt.net>
	<AANLkTi=J9cXKj+7Wi5AbL6FvwsqdJeb9UH6e-Yfs05v-@mail.gmail.com>
	<20101127085011.GA8663@dcvr.yhbt.net>
	<AANLkTimkvFSjiz60Bm90NQUa0+7-UE7-R35nVwU8LcQi@mail.gmail.com>
Message-ID: <AANLkTimPgtZ47OVJtBz5JMtHs8U5wk6=ULMSou_3e18z@mail.gmail.com>

On Sat, Nov 27, 2010 at 1:55 PM, Jake Douglas <jakecdouglas at gmail.com> wrote:
> On Sat, Nov 27, 2010 at 12:50 AM, Eric Wong <normalperson at yhbt.net> wrote:
>> Jake Douglas <jakecdouglas at gmail.com> wrote:
>>> On Wed, Nov 24, 2010 at 2:14 PM, Eric Wong <normalperson at yhbt.net> wrote:
>>> >
>>> > The normal Rails "render" path already seems[1] to add Content-Length;
>>> > are you doing something else to send responses from Rails?
>>>
>>> I am not doing anything special to send responses from Rails, only 'render'.
>>>
>>> I can see in my browser that keep-alive is set, and Content-Length is
>>> also set. It looks like the first couple requests finish quickly, and
>>> then the remaining take an additional 5 seconds each. It seems the
>>> browser is hanging for the default keep-alive timeout of 5 seconds on
>>> each request before proceeding. This happens with different browsers.
>>
>> Interesting. ?I rarely actually do anything with a full web browser,
>> but I can confirm keepalive works as expected with curl... ?Is there
>> anything in your error logs such as exceptions being thrown by your
>> app?
>>
>> Can anybody else reproduce this behavior Jake is seeing?
>>
>>> Is there additional information I can provide to give better insight
>>> into why this is happening?
>>
>> tcpdump or similar output would be useful, thanks!
>>
>> --
>> Eric Wong
>> _______________________________________________
>> Rainbows! mailing list - rainbows-talk at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rainbows-talk
>> Do not quote signatures (like this one) or top post when replying
>>
>
>
> It looks like the first issue is that by default Rails does not
> actually use Rack::ContentLength or set the Content-Length itself.
>
> The next issue is this bug, where Rack::ContentLength has some
> conditions that cause it to skip handling of the
> ActionDispatch::Response object from Rails. (ActionDispatch::Response
> < Rack::Response)
> http://rack.lighthouseapp.com/projects/22435/tickets/95-responsefinish-and-contentlength
>
> Fixing and enabling Rack::ContentLength seems to fix the issue for a
> single request to Rails from curl, but I am still getting the problem
> in my browser(s). Zbatery logs say that the request finishes quickly
> but the browser hangs for 5 seconds at a time. It is unclear to me
> what the cause is. I will try to do some more research and let you
> know the result.
>
> Thanks
>

After some more experimentation, it looks like the browser(s) fail to
close the connection after receiving the responses. Zbatery then waits
until the keepalive_timeout has expired, closes it, and accepts the
next connection. I gave the same application a try using Thin with
keep-alive and everything works fine. I spent a lot of time trying to
identify differences between the two, but the only useful thing I
managed to find is that the browser side never sends a FIN-ACK when
talking to Zbatery. For some reason, the browser doesn't think it's
finished. Any suggestions appreciated.

Thanks

From normalperson at yhbt.net  Sun Nov 28 05:07:05 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Sun, 28 Nov 2010 10:07:05 +0000
Subject: Zbatery/Rainbows keepalive problem?
In-Reply-To: <AANLkTimPgtZ47OVJtBz5JMtHs8U5wk6=ULMSou_3e18z@mail.gmail.com>
References: <AANLkTimSuK7-ihgCa00D-fot4U-FbZt2diQFndyN4uit@mail.gmail.com>
	<20101124211714.GA25256@dcvr.yhbt.net>
	<AANLkTi=oKL0Saw9sjf8Lrw-JakmOUKHnM363Qw=6JQO8@mail.gmail.com>
	<20101124221402.GA28625@dcvr.yhbt.net>
	<AANLkTi=J9cXKj+7Wi5AbL6FvwsqdJeb9UH6e-Yfs05v-@mail.gmail.com>
	<20101127085011.GA8663@dcvr.yhbt.net>
	<AANLkTimkvFSjiz60Bm90NQUa0+7-UE7-R35nVwU8LcQi@mail.gmail.com>
	<AANLkTimPgtZ47OVJtBz5JMtHs8U5wk6=ULMSou_3e18z@mail.gmail.com>
Message-ID: <20101128100705.GA23779@dcvr.yhbt.net>

Jake Douglas <jakecdouglas at gmail.com> wrote:
> After some more experimentation, it looks like the browser(s) fail to
> close the connection after receiving the responses. Zbatery then waits
> until the keepalive_timeout has expired, closes it, and accepts the
> next connection. I gave the same application a try using Thin with
> keep-alive and everything works fine. I spent a lot of time trying to
> identify differences between the two, but the only useful thing I
> managed to find is that the browser side never sends a FIN-ACK when
> talking to Zbatery. For some reason, the browser doesn't think it's
> finished. Any suggestions appreciated.

A shot in the dark, but I wonder if web browsers do anything special
with the Server: header with regard to keepalive.  Off the top of my
head, I know Thin includes the "Server:" header in all responses while
Rainbows! does not[1].

Can you try loading the Rainbows::ServerToken middleware to add
the Server header?

  use Rainbows::ServerToken, "foo/bar"

Any other differences in the headers the two servers send?

[1] - from what I can tell, rfc2616 does not require the Server: token,
      and recommends it to be configurable.

-- 
Eric Wong

From jakecdouglas at gmail.com  Sun Nov 28 12:26:01 2010
From: jakecdouglas at gmail.com (Jake Douglas)
Date: Sun, 28 Nov 2010 09:26:01 -0800
Subject: Zbatery/Rainbows keepalive problem?
In-Reply-To: <20101128100705.GA23779@dcvr.yhbt.net>
References: <AANLkTimSuK7-ihgCa00D-fot4U-FbZt2diQFndyN4uit@mail.gmail.com>
	<20101124211714.GA25256@dcvr.yhbt.net>
	<AANLkTi=oKL0Saw9sjf8Lrw-JakmOUKHnM363Qw=6JQO8@mail.gmail.com>
	<20101124221402.GA28625@dcvr.yhbt.net>
	<AANLkTi=J9cXKj+7Wi5AbL6FvwsqdJeb9UH6e-Yfs05v-@mail.gmail.com>
	<20101127085011.GA8663@dcvr.yhbt.net>
	<AANLkTimkvFSjiz60Bm90NQUa0+7-UE7-R35nVwU8LcQi@mail.gmail.com>
	<AANLkTimPgtZ47OVJtBz5JMtHs8U5wk6=ULMSou_3e18z@mail.gmail.com>
	<20101128100705.GA23779@dcvr.yhbt.net>
Message-ID: <AANLkTi=bt+cMTYdc+SMi0DJ3ZBB2iV8PryaWPm5-YqC-@mail.gmail.com>

On Sun, Nov 28, 2010 at 2:07 AM, Eric Wong <normalperson at yhbt.net> wrote:
> Jake Douglas <jakecdouglas at gmail.com> wrote:
>> After some more experimentation, it looks like the browser(s) fail to
>> close the connection after receiving the responses. Zbatery then waits
>> until the keepalive_timeout has expired, closes it, and accepts the
>> next connection. I gave the same application a try using Thin with
>> keep-alive and everything works fine. I spent a lot of time trying to
>> identify differences between the two, but the only useful thing I
>> managed to find is that the browser side never sends a FIN-ACK when
>> talking to Zbatery. For some reason, the browser doesn't think it's
>> finished. Any suggestions appreciated.
>
> A shot in the dark, but I wonder if web browsers do anything special
> with the Server: header with regard to keepalive. ?Off the top of my
> head, I know Thin includes the "Server:" header in all responses while
> Rainbows! does not[1].
>
> Can you try loading the Rainbows::ServerToken middleware to add
> the Server header?
>
> ?use Rainbows::ServerToken, "foo/bar"
>
> Any other differences in the headers the two servers send?
>
> [1] - from what I can tell, rfc2616 does not require the Server: token,
> ? ? ?and recommends it to be configurable.
>
> --
> Eric Wong
> _______________________________________________
> Rainbows! mailing list - rainbows-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rainbows-talk
> Do not quote signatures (like this one) or top post when replying
>


Adding the Server header does not change anything. The only other
difference I can see is that Rainbows! includes the Date header.
However, removing it also does not change the behavior. I am at a
complete loss now for what is causing this.

From normalperson at yhbt.net  Mon Nov 29 16:12:36 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Mon, 29 Nov 2010 21:12:36 +0000
Subject: Zbatery/Rainbows keepalive problem?
In-Reply-To: <AANLkTi=bt+cMTYdc+SMi0DJ3ZBB2iV8PryaWPm5-YqC-@mail.gmail.com>
References: <AANLkTimSuK7-ihgCa00D-fot4U-FbZt2diQFndyN4uit@mail.gmail.com>
	<20101124211714.GA25256@dcvr.yhbt.net>
	<AANLkTi=oKL0Saw9sjf8Lrw-JakmOUKHnM363Qw=6JQO8@mail.gmail.com>
	<20101124221402.GA28625@dcvr.yhbt.net>
	<AANLkTi=J9cXKj+7Wi5AbL6FvwsqdJeb9UH6e-Yfs05v-@mail.gmail.com>
	<20101127085011.GA8663@dcvr.yhbt.net>
	<AANLkTimkvFSjiz60Bm90NQUa0+7-UE7-R35nVwU8LcQi@mail.gmail.com>
	<AANLkTimPgtZ47OVJtBz5JMtHs8U5wk6=ULMSou_3e18z@mail.gmail.com>
	<20101128100705.GA23779@dcvr.yhbt.net>
	<AANLkTi=bt+cMTYdc+SMi0DJ3ZBB2iV8PryaWPm5-YqC-@mail.gmail.com>
Message-ID: <20101129211236.GA18934@dcvr.yhbt.net>

Jake Douglas <jakecdouglas at gmail.com> wrote:
> Adding the Server header does not change anything. The only other
> difference I can see is that Rainbows! includes the Date header.
> However, removing it also does not change the behavior. I am at a
> complete loss now for what is causing this.

A few more things, are these GET or POST requests (or something else)?
Is it done via AJAX/XmlHttpRequest?

Can you put together a redistributable test case as a standalone app
that I can hammer on locally?

-- 
Eric Wong

From jakecdouglas at gmail.com  Mon Nov 29 17:45:11 2010
From: jakecdouglas at gmail.com (Jake Douglas)
Date: Mon, 29 Nov 2010 14:45:11 -0800
Subject: Zbatery/Rainbows keepalive problem?
In-Reply-To: <20101129211236.GA18934@dcvr.yhbt.net>
References: <AANLkTimSuK7-ihgCa00D-fot4U-FbZt2diQFndyN4uit@mail.gmail.com>
	<20101124211714.GA25256@dcvr.yhbt.net>
	<AANLkTi=oKL0Saw9sjf8Lrw-JakmOUKHnM363Qw=6JQO8@mail.gmail.com>
	<20101124221402.GA28625@dcvr.yhbt.net>
	<AANLkTi=J9cXKj+7Wi5AbL6FvwsqdJeb9UH6e-Yfs05v-@mail.gmail.com>
	<20101127085011.GA8663@dcvr.yhbt.net>
	<AANLkTimkvFSjiz60Bm90NQUa0+7-UE7-R35nVwU8LcQi@mail.gmail.com>
	<AANLkTimPgtZ47OVJtBz5JMtHs8U5wk6=ULMSou_3e18z@mail.gmail.com>
	<20101128100705.GA23779@dcvr.yhbt.net>
	<AANLkTi=bt+cMTYdc+SMi0DJ3ZBB2iV8PryaWPm5-YqC-@mail.gmail.com>
	<20101129211236.GA18934@dcvr.yhbt.net>
Message-ID: <AANLkTimE+t6o1U--N3MP7btZa0xKXEMHnhTTW=8Sn_x0@mail.gmail.com>

On Mon, Nov 29, 2010 at 1:12 PM, Eric Wong <normalperson at yhbt.net> wrote:
> Jake Douglas <jakecdouglas at gmail.com> wrote:
>> Adding the Server header does not change anything. The only other
>> difference I can see is that Rainbows! includes the Date header.
>> However, removing it also does not change the behavior. I am at a
>> complete loss now for what is causing this.
>
> A few more things, are these GET or POST requests (or something else)?
> Is it done via AJAX/XmlHttpRequest?
>
> Can you put together a redistributable test case as a standalone app
> that I can hammer on locally?
>
> --
> Eric Wong
> _______________________________________________
> Rainbows! mailing list - rainbows-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rainbows-talk
> Do not quote signatures (like this one) or top post when replying
>

They are normal GET requests, not XHRs. I'll try to get you a simple
test case sometime this week.