Folks,
If nginx is built on FreeBSD, "proxy_ignore_client_abort on;" has
no/little effect, because TCP half-closes cause a connection drop
even if not speaking to a proxy backend.
Situation: PGP clients talk to PGP keyservers using the HKP protocol,
which is a very light layer over HTTP. In GnuPG, if the cURL library
was not available at build time, a mock-curl "curl-shim" implementation
is used instead. In GnuPG 2.0.x, this code uses a TCP half-close to
indicate when the sender has finished sending. This was a mistake and
has been fixed for the next release, but people running PGP keyservers
need to deal with the existing installed userbase.
For various (good) reasons, the common PGP keyserver software is run
with a reverse proxy in front of it, and nginx is a popular choice.
nginx will default to drop connections on the shutdown, for reasons
previously explained on this list. Enabling proxy_ignore_client_abort
is, as far as I understand matters, supposed to allow these shutdowns to
not be considered an abort.
Temporarily turning on an error log for the :11371 server block (that's
the HKP default port) gives:
2013/02/28 09:11:54 [info] 34110#0: *51
kevent() reported that client closed connection while waiting for request,
client: 2a02:898:0:20::57:1, server: [2a02:898:31:0:48:4558:73:6b73]:11371
"proxy_ignore_client_abort on" avoids enabling logic in
src/http/ngx_http_upstream.c which would log:
kevent() reported that client prematurely closed
connection, so upstream connection is closed too
That's _not_ the error message here; instead, what we get comes from
src/http/ngx_http_request.c in ngx_http_keepalive_handler().
As far as I can tell, as long as NGX_HAVE_KQUEUE is defined, it is
impossible to avoid this handling.
nginx folks: is this something you're likely to fix, or is this far
enough outside of supportable behaviour that you consider the current
situation a feature, not a bug?
I'm not sufficiently familiar with the nginx code base to find a fix for
this and don't currently have time to get familiar, sorry. :(
Thanks,
-Phil
PS: nginx mail-server configuration is broken; it's checking SMTP Envelope
Sender against the subscription list, not the RFC5322.From: header, so
breaks on things such as PRVS. Posting via manual injection to your
mail-server. :(
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
