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