> HTTP/2 connection coalescing is certainly related but totally separate, as > that > controls how existing connections may be used for pending requests (even > across different host names) and SSL session IDs for how to use meta-data to > restablish a connection faster. > > libcurl has no such connection coalescing logic currently, but it would be > interesting to feature that at some point. >
To follow up on this thread, I posted a question to the HTTP WG asking about TLS session ID reuse and had some very interesting response. The thread can be found at https://lists.w3.org/Archives/Public/ietf-http-wg/2016OctDec/0713.html. In one of the later messages, Eric Rescorla highlights a section of RFC 6066 that makes it clear that a server MUST NOT accept a request to resume a TLS session if the SNI is different. Clients may do that but the server shouldn't support it. I think therefore that libcurl is behaving well in recent versions and is working as expected. > For the interested, I blogged about how HTTP/2 connection coalescing is > done (or not done) by browsers a while ago: > Your blog post is my go-to for understanding HTTP/2 connection coalescing in the less abstract sense (RFC 7540 seems to talk too vaguely in my opinion). Interestingly, h2 coalescing seems to contradict a different part of RFC 6066. Regards Lucas ------------------------------------------------------------------- List admin: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
