> 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
Received on 2016-12-15