Connection header for inflight return messages during shutdown

[marius.predescu@…]

Hi,

During an nginx reload, workers perform a gracefully shutdown, closing listening and idle sockets and waiting for in progress messages to complete after which, those connections will be closed also; however, even nginx knows will immediately close the connection it still sends a "Connection: keep-alive" header.

RFC7230 states that "Connection: close" indicates that sender is going to close the connection after message is sent, which is exactly what nginx is going to do when shutting down; so sending Connection: close instead of Connection: keep-alive header seems to be a more polite behavior towards clients.

I do understand that sending "Connection: keep-alive" and closing connection afterwards is still in the RFC boundaries as detailed in: ​https://trac.nginx.org/nginx/ticket/1022; still, it would be nicer to send Connection: close when next behavior is 100% known. Note that this is about inflight messages only, and not about idle connections as 1022 case is focused on.

​https://tools.ietf.org/html/rfc7230#section-6.1

   The "close" connection option is defined for a sender to signal that
   this connection will be closed after completion of the response.  For
   example,

     Connection: close

   in either the request or the response header fields indicates that
   the sender is going to close the connection after the current
   request/response is complete (Section 6.6).

I would really appreciate your comments on this issue,
Thank you!

[Maxim Dounin]

While it might be possible to return Connection: close in some responses - as long as it is already known that nginx worker is shutting down when the response header is generated - it is going to be a minor enhancement at best, since in most cases what takes time is transferring the response body, and it is not possible to return Connection: close if the worker shutdown is initiated after the response header is already sent.