Meaning of proxy_ignore_client_abort

Maxim Dounin mdounin at mdounin.ru
Tue Dec 19 17:45:21 UTC 2023


Hello!

On Tue, Dec 19, 2023 at 04:02:46PM +0100, Jan Prachař wrote:

> Hello,
> 
> I have proxy module configured with proxy_ignore_client_abort on; but connection to
> upstream is still being closed. This is in debug log:
> 
>  writev() failed (32: Broken pipe) while sending to client, ...
>  http write filter FFFFFFFFFFFFFFFF
>  http copy filter: -1 ...
>  pipe read upstream: 0
>  pipe buf free s:0 t:1 f:0 000055DEBEF95EC0, pos 000055DEBEF95EC0, size: 473 file: 0,
> size: 0
>  pipe buf free s:0 t:1 f:0 000055DEBEF91EB0, pos 000055DEBEF91EB0, size: 0 file: 0, size:
> 0
>  pipe length: 22594336
>  event timer: 23, old: 15583745, new: 15583837
>  http upstream downstream error
>  finalize http upstream request: -1
>  finalize http proxy request
>  close http upstream connection: 23
> 
> It seems, that check if ignore_client_abort is on, is missing here: 
> https://trac.nginx.org/nginx/browser/nginx/src/http/ngx_http_upstream.c#L4223
> 
> Or is there any reason why the connection is closed regardless the ignore_client_abort?

When an error while sending to the client occurs, like in the log 
you've provided, the connection is closed regardless of the 
"proxy_ignore_client_abort" directive.  The directive only 
affects nginx behaviour when nginx is waiting for a response from 
the upstream server: with "proxy_ignore_client_abort on;" nginx 
will not try to detect if the client already closed the 
connection and close the upstream connection accordingly.  When 
the response is being sent, the upstream server is expected to be 
smart enough to recognize that the connection was closed.

Note that the docs say 
(http://nginx.org/r/proxy_ignore_client_abort):

: Determines whether the connection with a proxied server should 
: be closed when a client closes the connection without waiting for 
: a response.

While it probably can be improved, it explicitly says "without 
waiting for a response", and nothing about "when reading a 
response".

-- 
Maxim Dounin
http://mdounin.ru/


More information about the nginx-devel mailing list