I'm using NGINX as a reverse proxy in conjunction with the ngx_http_fastcgi_module. It is proxying requests to a custom Golang FastCGI that executes a PHP-CGI process.
There are requests that take an excessive amount of time because of some complex code that our customers are using. If the User clicks a different link while waiting for the request the browser cancels the previous request and NGINX sees it:
[info] 24#24: *1516 client 1.2.3.4 closed keepalive connection
which is great! But my upstream PHP-CGI process continues to run until it times out. This can consume a lot of resources if the user continues to click more links. I suspect my problem might be that NGINX isn't explicitly cancelling the upstream request. I've found the setting fastcgi_ignore_client_abort and it seems that by default it would not be ignored (which is good). It says:
Determines whether the connection with a proxied server should be closed when a client closes the connection without waiting for a response.
Does that mean it's actually terminating the upstream request as well, or just ignoring the upstream request/response?
And if it should be sending a signal upstream, is there a way in NGINX that I can verify it is working as expected?
On the Fast-CGI side of things the Golang server is listening for a Done() from the http.Request.Context() while it executes the request. If NGINX is explicitly terminating the upstream request we think that should detect it. Does anyone know if that's incorrect?
