applied: [PATCH http-server 1/1] apiserver: send TLS close notify at the end of streamed responses

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

On Tue, 03 Nov 2026 16:52:23 +0100, Michael Köppl wrote:
> A streamed response (e.g. for the single file restore download), has no
> Content-Length nor chunked encoding, so the client can only tell where
> the body ends by the connection being closed. The response accounced
> 'Connection: Keep-Alive' and, at the end of the stream, push_shutdown()
> shut down the socket directly, bypassing the TLS layer. The client then
> receives a TCP FIN without a TLS close notify [0].
> 
> [...]

Applied, with s/apiserver/response/ for the subject, thanks!

[1/1] apiserver: send TLS close notify at the end of streamed responses
      commit: d4d74a6de412f9a946089cbfccec62b519557c73

Though in local tests the patch alone did not yet make the close notify a
reliable end-of-download signal, so I applied three commits before it:

- c2d96d0: with output still queued at the end of a stream, the close
  notify could only get queued and the following shutdown lost it. curl
  thus still failed with error 56 after receiving a complete download.

- 7ba3802: a disconnect aborting a stream could send a close notify too,
  making a truncated download look complete. That goes back to 07e56cc,
  but clients can only rely on the close notify if it's not sent then.

- 124c146: on a reused connection, a pipelined request could replace the
  source of an active stream, so the client received the other response
  as the body. With push_shutdown() gone, that could now end with a
  clean close notify too.