Connection: keep-alive

[dgleo2]

Could it support header : Connection: keep-alive easily ?

Connections is always close on each send.
Best.

[bitm0de]

What's the use case?

Typically for embedded systems with less resources you wouldn't want this to be set as it keeps socket connections open and in busier programs this can tie up resources leading to socket exhaustion. Unless you're sending requests in rapid succession, which I wouldn't advise anyways if you can find another means to get the data, there's not going to be much benefit. Because the implementation uses a pool of client connections too, this might be worse overall.

[dgleo2]

Hi Troy, Thank you for responding, The use cas is to control a device using REST API over https wit SSL. I use your code on a 3 series and it works but the device I am controlling have limited socket and renegotiate certificate at each connection slow the thing, the device prefer keeping session alive and this accelerate the transfer. I am not a SIMPL# programmer. Any tips are welcome. Regards. - Daniel Envoyé de mon mobile Le ven. 30 mai 2025 à 00:49, Troy Garner ***@***.***> a écrit :

…

*bitm0de* left a comment (bitm0de/HttpsUtility#13) <#13 (comment)> What's the use case? Typically for embedded systems with less resources you wouldn't want this to be set as it keeps socket connections open and in busier programs this can tie up resources leading to socket exhaustion. Unless you're sending requests in rapid succession, which I wouldn't advise anyways if you can find another means to get the data, there's not going to be much benefit. Because the implementation uses a pool of client connections too, this might be worse overall. — Reply to this email directly, view it on GitHub <#13 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGAY62WK7CNPAA4POTP5YQT3A7POHAVCNFSM6AAAAAB6DVXMV2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMRRGIZDCMBXGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[bitm0de]

That could be a potential use case, perhaps a digital signal as a flag to enable keep-alive would be good. It would need to be reconciled with the pooling of HTTPS clients behind the scenes however to allow for the benefits to be had.

Currently, simultaneous requests from the pool are likely to use different clients from the pool so I'm not sure if this would yield different results without more granular orchestration around how the requests are being dispatched.