Nginx write content to client instead of 504 when fastcgi timeout expired in configuration

[Zhe Yang]

I wrote a multi-thread fastcgi application which print http header, then sleep for 5 seconds before writing the actual data. Then I set fastcgi timeout to 4s in nginx.

When nginx's query get timeout, nginx closes the socket, and log timeout to the error log, but it write the http header to client.

[Maxim Dounin]

Much like with ​fastcgi_next_upstream, it's not possible to fix things if part of a response was already sent to a client. Quoting fastcgi_next_upstream docs:

One should bear in mind that passing a request to the next server is only possible if nothing has been sent to a client yet. That is, if an error or timeout occurs in the middle of the transferring of a response, fixing this is impossible.

Best we can do here is to flush buffers to make sure parts of a response we've already got from an upstream server are sent to a client, and make sure a response isn't interpreted by a client as a complete one. This is believed to be what nginx 1.5.3+ does with the following ​change:

    *) Change: now after receiving an incomplete response from a backend
       server nginx tries to send an available part of the response to a
       client, and then closes client connection.

[Zhe Yang]

I agree. In general, this is the only way to fix the problem. But a normal close() won't let the client think the content isn't complete.

With nginx 1.4.1, it's close()d normally. Does 1.5.3+ set SO_LINGER before close(), a.k.a close by RST?

[Maxim Dounin]

The HTTP protocol allows to detect if a response isn't complete as long as either Content-Length or Transfer-Encoding: chunked is used. Close with RST isn't a good approach as it might not allow a client to read a response at all.