Client closed keepalive connection

Wilson Bilkovich wilsonb at gmail.com
Fri Apr 27 22:47:04 MSD 2007


On 4/27/07, Igor Sysoev <is at rambler-co.ru> wrote:
> On Fri, Apr 27, 2007 at 02:23:14PM -0400, Wilson Bilkovich wrote:
>
> > 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?
>
> No. The "Expect: continue/100 Continue" dialog should work as following:
>
> client -> "Expect: continue" -> nginx
> client <- "100 continue"     <- nginx
> client -> BODY               -> nginx
>                                 nginx -> whole request       -> backend
>                                         (without Expect")
>
> clint <-                        nginx <- response            <- backend
>
> but nginx does not currently support "Expect".
>
> In your case nginx passes "100 continue" and thinks that request is over.
>
>

I am sending the '100 Continue' and the other HTTP/1.1 status line as
a single chunk from the back-end.  There's actually no keepalive
conversation in progress.
With keepalive_timeout set to 0, it seems to happen much more often.
I'm testing it now.





More information about the nginx mailing list