While working on https://github.com/Pylons/waitress/pull/428, I pondered the idea that closing the connection should cause client-side complaints of broken connections. It looks like Task.close_on_finish is sometimes set to true alongside a Connection: close header and other times not. If headers have not been written yet, it makes sense to always include Connection: close when close_on_finish is set. This pull request adds a utility that sets both of these values together. This results in better connection handling for clients.
There are a couple caveats:
If Connection already has a directive in the response headers, we will not set it
If headers have already been sent to the client, there is of course nothing we can do
There is also not particularly simple way to ensure that people call this method correctly unless we want to introduce a property for this variable — but I'm not really into properties with side-effects.
I believe this change does not invalidate #428 but it does also resolve #427.
While working on https://github.com/Pylons/waitress/pull/428, I pondered the idea that closing the connection should cause client-side complaints of broken connections. It looks like
Task.close_on_finishis sometimes set to true alongside aConnection: closeheader and other times not. If headers have not been written yet, it makes sense to always includeConnection: closewhenclose_on_finishis set. This pull request adds a utility that sets both of these values together. This results in better connection handling for clients.There are a couple caveats:
Connectionalready has a directive in the response headers, we will not set itThere is also not particularly simple way to ensure that people call this method correctly unless we want to introduce a property for this variable — but I'm not really into properties with side-effects.
I believe this change does not invalidate #428 but it does also resolve #427.