Hello!
On Tue, Mar 19, 2013 at 03:45:10PM +1100, Robert Mueller wrote:
>
> > > When an https client drops it's connection, the upstream http proxy
> > > connection is not dropped. If nginx can't detect an https client
> > > disconnect properly, that must mean it's leaking connection information
> > > internally doesn't it?
> >
> > No. It just can't say if a connection was closed or not as there
> > are pending data in the connection, and it can't read data (there
> > may be a pipelined request). Therefore in this case, being on the
> > safe side, it assumes the connection isn't closed and doesn't try
> > to abort upstream request.
>
> Oh right I see now.
>
> So the underlying problem is that the nginx stream layer abstraction
> isn't clean enough to handle low level OS events and then map them
> through the SSL layer to read/write/eof conceptual events as needed.
> Instead you need an OS level "eof" event, which you then assume maps
> through the SSL abstraction layer to a SSL stream eof event.
Not exactly. The underlying problem is that BSD sockets API
doesn't provide standard means to detect EOF without reading all
pending data, and hence OS-specific extensions have to be used to
reliably detect pending EOFs.
> Ok, so I had a look at the kqueue eof handling, and what's needed for
> epoll eof handling, and created a quick patch that seems to work.
>
> Can you check this out, and see if it looks right. If so, any chance you
> can incorporate it upstream?
>
> http://robm.fastmail.fm/downloads/nginx-epoll-eof.patch
>
> If there's anything you want changed, let me know and I'll try and fix
> it up.
I don't really like what you did in ngx_http_upstream.c. And
there are more places where ev->pending_eof is used, and probably
at least some of these places should be adapted, too.
Additionally, poll_ctl(2) manpage claims the EPOLLRDHUP only
available since Linux 2.6.17, and this suggests it needs some
configure tests/conditional compilation.
Valentin is already worked on this, and I believe he'll be able to
provide a little bit more generic patch.
--
Maxim Dounin
http://nginx.org/en/donation.html
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
On Tue, Mar 19, 2013 at 03:45:10PM +1100, Robert Mueller wrote:
>
> > > When an https client drops it's connection, the upstream http proxy
> > > connection is not dropped. If nginx can't detect an https client
> > > disconnect properly, that must mean it's leaking connection information
> > > internally doesn't it?
> >
> > No. It just can't say if a connection was closed or not as there
> > are pending data in the connection, and it can't read data (there
> > may be a pipelined request). Therefore in this case, being on the
> > safe side, it assumes the connection isn't closed and doesn't try
> > to abort upstream request.
>
> Oh right I see now.
>
> So the underlying problem is that the nginx stream layer abstraction
> isn't clean enough to handle low level OS events and then map them
> through the SSL layer to read/write/eof conceptual events as needed.
> Instead you need an OS level "eof" event, which you then assume maps
> through the SSL abstraction layer to a SSL stream eof event.
Not exactly. The underlying problem is that BSD sockets API
doesn't provide standard means to detect EOF without reading all
pending data, and hence OS-specific extensions have to be used to
reliably detect pending EOFs.
> Ok, so I had a look at the kqueue eof handling, and what's needed for
> epoll eof handling, and created a quick patch that seems to work.
>
> Can you check this out, and see if it looks right. If so, any chance you
> can incorporate it upstream?
>
> http://robm.fastmail.fm/downloads/nginx-epoll-eof.patch
>
> If there's anything you want changed, let me know and I'll try and fix
> it up.
I don't really like what you did in ngx_http_upstream.c. And
there are more places where ev->pending_eof is used, and probably
at least some of these places should be adapted, too.
Additionally, poll_ctl(2) manpage claims the EPOLLRDHUP only
available since Linux 2.6.17, and this suggests it needs some
configure tests/conditional compilation.
Valentin is already worked on this, and I believe he'll be able to
provide a little bit more generic patch.
--
Maxim Dounin
http://nginx.org/en/donation.html
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx