Client closed keepalive connection
wilsonb at gmail.com
Fri Apr 27 22:23:14 MSD 2007
On 4/27/07, Igor Sysoev <is at rambler-co.ru> wrote:
> On Fri, Apr 27, 2007 at 02:11:52PM -0400, Wilson Bilkovich wrote:
> > On 4/27/07, Igor Sysoev <is at rambler-co.ru> wrote:
> > >On Fri, Apr 27, 2007 at 01:39:40PM -0400, Wilson Bilkovich wrote:
> > >
> > >> I am having some difficulty with nginx as a load balancer on MacOS X
> > >> (Intel).
> > >> I am running 0.5.19, but the problem occurs with recent earlier
> > >> versions as well.
> > >>
> > >> With "use kqueue"
> > >> 2007/04/26 22:26:15 [info] 4133#0: *3048 kevent() reported that client
> > >> 192.168.0.100 closed keepalive connection
> > >>
> > >> With "use poll"
> > >> 2007/04/26 22:59:48 [info] 10189#0: *375 client 192.168.0.100 closed
> > >> keepalive connection
> > >>
> > >> On the client side, I get a "Socket closed." error. My HTTP client is
> > >> not configured to use keepalive, which makes the error message seem
> > >> very strange.
> > >> The only 'weird' thing I am doing is sending a '100 Continue' response
> > >> from the back-end server.
> > >> Does nginx have different behavior when I send back a 100?
> > >
> > >Does the client do POST and pass "Expect: continue" ?
> > >nginx does not support "Expect: continue/100 Continue" dialog because
> > >current browsers still do not support it (at least I never see).
> > >
> > >So the client askes "Expect: continue", nginx passes the request
> > >to backend, the backend responses "100 Continue". nginx sends it
> > >to the client and goes to keep-alive state.
> > The client is not passing Expect: continue. I'm mimicking the behavior
> > of a 3rd-party app that 'unexpectedly' sends a 100 Continue response
> > before the 'real' response code. These are POST requests though, yes.
> > In the nginx access log, '100' is the status code shown. Does nginx
> > enable keep-alive automatically when that happens?
> keep-alive in nginx has no relation to "100".
> nginx enables keep-alive if keepalive_timeout >0 and
> *) an request has the "Connection: keep-alive" header
> 2* or an request has no "Connection" header and the request version is > 1.0.
OK, so if I set keepalive_timeout to 0, that should reveal whether
this is actually the problem I am seeing?
More information about the nginx