Hello!

On Tue, Nov 19, 2019 at 10:29:37AM -0500, feanorknd wrote:

> Hello...
>
> Few days ago I have had this problem... let me explain with log lines:
>
> X.X.X.X - - [16/Nov/2019:04:36:17 +0100] "POST /api/budgets/new HTTP/2.0"
> 200 2239 "----" "Mozilla/5.0 (iPhone; CPU iPhone OS 13_2 like Mac OS X)
> AppleWebKit/605.1.15 (KHTML, like Gecko) GSA/86.0.276299193 Mobile/15E148
> Safari/605.1" Exec: "2.190" Conn: "10" Upstream Time: "2.185" Upstream
> Status: "200"
>
> X.X.X.X - - [16/Nov/2019:04:36:55 +0100] "POST /api/budgets/new HTTP/2.0"
> 499 0 ""----"" "Mozilla/5.0 (iPhone; CPU iPhone OS 13_2 like Mac OS X)
> AppleWebKit/605.1.15 (KHTML, like Gecko) GSA/86.0.276299193 Mobile/15E148
> Safari/605.1" Exec: "0.147" Conn: "1" Upstream Time: "0.142" Upstream
> Status: "-"
>
> In the first line, there is nothing of interest... just the POST request was
> completely fine.
>
> In the second request, there was a client disconnection and POST request was
> not complete, as given by the 499 logged error.
>
> The problem was:
> - the incomplete POST data was sent from nginx to the backend fastcgi server
> somehow.
> - that code did process the incomplete request data and generated a corrupt
> entry in certain database... another history.

In no particular order:

- By default, nginx will pass the request to the backend server
only when it's completely received from the client, including
the request body. You can change things by explicitly using
"fastcgi_request_buffering off;", but this shouldn't change things
much as long as your backend is properly written.

- Any backend server is expected to verify if it received complete
request, as the connection between nginx and backend can be
broken from unrelated reasons, such as network issues.

- An incomplete request will result in 400, not 499. The 499
error means that the request was complete, but the client closed
connection before the response was generated.

Given the above, most likely what you've seen was a connection
close by the client after sending a complete request. For
example, this might have happened when nginx was sending the
request body to the backend.

By default, if the client closes the connection - nginx closes the
connection with the backend to let the backend know that no
further request processing is needed. A properly written backend
is expected to handle this correctly, as it is anyway have to
check the request integrity.

If for some reason your backend cannot cope with this, there is
the fastcgi_ignore_client_abort directive to control this
behaviour (http://nginx.org/r/fastcgi_ignore_client_abort).

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx