Hello,

I'd like to understand the reasoning behind the "TCP-only pooling" decision. As I read it, the HTTPS flow is now:

1. Get TCP connection (from pool or prewarm)
2. Upgrade in-place via ssl:connect/2
3. Run the request
4. Close the connection (SSL never returned to pool)
5. Prewarm a fresh TCP connection

This effectively means that every HTTPS request performs a full TLS handshake, since SSL connections are never reused. The TCP pool only removes the TCP handshake cost, while the TLS cost (RTT + key exchange + certificate validation) remains per request.

A few specific questions:

• The changelog describes this as a security improvement ("SSL state never shared between requests"). What's the threat model here? Keep-alive TLS connections are standard practice in browsers and most HTTP clients, and TLS session resumption shares cryptographic state across handshakes anyway.
• Does hackney enable TLS session resumption (session tickets / reuse_sessions) to reduce the per-request handshake cost?
• Would you be open to SSL pooling as an opt-in pool option for HTTPS-heavy workloads?

Silviu