Note from 3 July 2020

@bagder hi Daniel, reading https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/ (yes, I'm late 😅)

If DNS B.example.com returns 192.168.0.2 and 192.168.0.3, is TLS really enough to be sure it also works on 192.168.0.1?

BTW, there's a typo near the end: "both IPv4 and IPv4 addresses".

11 reactions

11 replies

Nicolas Hoizey
BTW, there's a typo near the end: "both IPv4 and IPv4 addresses".
- 3 July 2020, 14:48
- Source
Daniel Stenberg
I'm not sure what you're asking. Are you asking if my explanation is correct of how Firefox does connection coalescing?
- 3 July 2020, 14:51
- Source
Nicolas Hoizey
I'm not questioning your explanation at all.

I don't understand how Firefox can make sure B can answer on the same IP as A when DNS doesn't list it.
- 3 July 2020, 15:05
- Source
Daniel Stenberg
that's not what it says, it says it can reuse/coalesce the connection for A with B if DNS and the certs have overlap
- 3 July 2020, 15:30
- Source
Nicolas Hoizey
As I understand it:
- A is on 1 and 2
- Firefox connects to 1
- TLS says * are the same
- B is on 2 and 3
- 2 and 3 are in *, so 1 (which is also) is reused

That's what I understand in "It will reuse […] A and ask for host B’s content over that single shared connection"
- 3 July 2020, 15:57
- Source
Daniel Stenberg
yes, that seems accurate
- 3 July 2020, 15:57
- Source
Nicolas Hoizey
Ok, so I wonder how it reacts if B is not reachable with 192.168.0.1 … 🤷‍♂️
- 3 July 2020, 17:53
- Source
Daniel Stenberg
I'm pretty sure that doesn't matter. The point is that the site admins have specified that A and B overlap.
- 3 July 2020, 17:56
- Source
Nicolas Hoizey
Ok, thanks.

Maybe I should let go… 😉
- 3 July 2020, 17:57
- Source
Daniel Stenberg
you don't have to, but if you want to argue that they're doing it wrong you should talk to Firefox engineers, not me...
- 3 July 2020, 17:59
- Source
Nicolas Hoizey
I really do not want to argue anything, just to understand how/why it works.
- 3 July 2020, 18:00
- Source

Simon Hearne

Caching Header Best Practices
- Nicolas Hoizey
- 14 October 2022
- WebPerf, HTTP
- 4 reactions
Client-side caching is a key technique to improving front-end speed and user experience. Whilst it may appear complex and risky, investing the time…
Note from 15 March 2022
- Nicolas Hoizey
- 15 March 2022
- Cloudflare, Fastly, HTTP, WebPerf
- 3 reactions
TIL: #Cloudflare doesn't support the Vary HTTP header, which means the origin server can't do any content negotiation, for example send WebP or AVIF for a JPEG request…

https://developers.cloudflare.com/cache/about/cache-control/#other

#Fastly supports it, just saying… 😅

Note from 3 July 2020

Related contents with similar topics