> > 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.

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.

Rob

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx