Opened 5 years ago
Closed 3 years ago
#1823 closed enhancement (fixed)
Connection header for inflight return messages during shutdown
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | nginx-core | Version: | 1.13.x |
Keywords: | Cc: | ||
uname -a: | Linux | ||
nginx -V: | nginx version: 1.13.6 |
Description
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!
Change History (2)
comment:1 by , 5 years ago
Type: | defect → enhancement |
---|
comment:2 by , 3 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Fixed in 96ae8e57b3dd (nginx 1.21.6), thanks for prodding this.
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 returnConnection: close
if the worker shutdown is initiated after the response header is already sent.