Understanding "proxy_ignore_client_abort" functionality

[Maxim Dounin]

Hello!

On Tue, Sep 02, 2014 at 12:57:15PM -0400, shmulik wrote:

> Hi,
> I'm trying to understand how "proxy_ignore_client_abort" should affect
> connection to upstream server once client closes the connection, since it
> seems to behave different than i'm expecting.

[...]

> 3. And the part that surprised me - in "ngx_http_upstream_process_request",
> if "downstream_error" flag is set, we also close the connection to upstream,
> regardless of the "proxy_ignore_client_abort" config:
> 
> //-------------------------------------------------------------------------------------------------
>     if (p->downstream_error) {
>         ngx_log_debug0(NGX_LOG_DEBUG_HTTP, r->connection->log, 0,
>                        "http upstream downstream error");
> 
>         if (!u->cacheable && !u->store && u->peer.connection) {
>             ngx_http_upstream_finalize_request(r, u, NGX_ERROR);
>         }
>     }
> //-------------------------------------------------------------------------------------------------
> 
> I'd expect the "proxy_ignore_client_abort" flag to be checked in the "if" in
> #3 as well (=don't close upstream connection if the flag is true).
> 
> My first thought was that if the file should not be stored or cached - there
> is no reason to continue the connection to upstream, so that this is by
> design. However if that's the case then proxy_ignore_client_abort is
> redundant.

The proxy_ignore_client_abort flag specifies whether nginx will 
monitor possible connection close while waiting for an upstream 
server response.  If an error occurs while sending a response, the 
connection will be closed regardless of the flag, much like if 
there where no nginx at all.

Switching proxy_ignore_client_abort to on may be needed in the 
following cases I'm aware of:

- you need to maintain compatibility with clients that half-close 
  connections after sending a request;

- your backend doesn't check if a connection is closed while 
  generating a response (and hence closing the connection by nginx 
  will not abort the request processing on the backend), and at the 
  same time you want nginx to maintain limit_conn numbers mostly 
  matching actual resources used on the backend;

- your backend does check if a connection is closed, but you don't 
  want this to happen as you code can't really cope with it.

-- 
Maxim Dounin
http://nginx.org/