nginx/KQUEUE breaks proxy_ignore_client_abort

[Maxim Dounin]

Hello!

On Fri, Mar 01, 2013 at 03:22:51AM -0500, Phil Pennock wrote:

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

It looks like you are running nginx with experimental SPDY patch, 
and it broke things here.  Try recompiling nginx without SPDY 
patch to see if it helps.

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

Unfortunately, there is no way to properly reject messages at SMTP 
level (i.e. to avoid sending bounces) and doing checks based on 
message headers at the same time.

If you use different envelope from and message from addresses and 
have problems with posting - just subscribe your envelope from 
address to the mailing list with mail delivery disabled.

-- 
Maxim Dounin
http://nginx.org/en/donation.html