herhor67 wrote: ↑Mon Apr 01, 2024 9:19 am
So it is fine to check the send functions too? Why are they not tested in examples, for brevity?
Not 100% sure, but, since sending happens 'through' the HTTP server, I imagine the server will detect (some) transmission errors and close the socket itself.
Btw, if I understand correctly, the Connection: keep-alive is the same as keep-alive packets?
Not necessarily. Originally, HTTP required that only one request would be sent per connection. Closing the connection from the server side signalled the end of the response data. For better efficiency, persistent connections were introduced with HTTP/1.1 which allow multiple requests to be sent and responded to over a single connection. The client advertises its support/wish for a persistent connection via the Connection: keep-alive header, and, in the most basic implementation, the server just 'reacts' to this by simply not closing the connection after each request.
If I want to keep connections alive as long as there is something to transfer (multipart) but not after the transfer, should I just return errors in any case? Or is this configurable somehow?
Normally it would be the
client which closes the connection when it has no more use for it. The HTTP server can also automatically
'purge' unused connections.
You could also use
httpd_req_to_sockfd() and
httpd_sess_trigger_close() to 'manually' close the socket from the server.
The same may work by returning an error from the URI handler, but I'm not sure about how the server will handle any yet unsent response data in that case. Might have to also enable SO_LINGER in the server config.