4 ms·

As the reporter already stated, just because the HTTP/2 spec permits it, that doesn't make it a good idea. Now Firefox may "resolve" a hostname to a different I

As the reporter already stated, just because the HTTP/2 spec permits it, that doesn't make it a good idea. Now Firefox may "resolve" a hostname to a different IP based on whether it might have connected to a different hostname before. I don't want to imagine what bugs this will cause. And for what? To save another (probably already cached) DNS lookup?

pornel 4y ago
The time to bikeshed whether it's a good idea was at IETF when HTTP/2 has been designed. This feature has been in production for over 6 years. Note that both hostnames must be in the same TLS certificate. You won't get random hosts coalesced by accident. You have to specifically obtain a TLS certificate that contains multiple of your hosts, and their DNS entries have to have at least one IP address in common. And then the server can still return an HTTP error that tells the browser to stop coalescing and retry with a fresh connection. In practice this feature is commonly used to reuse a single CDN connection to fetch from multiple hosts behind the same CDN (e.g. www.example.com + assets.example.com), and avoids fragmenting per-connection request prioritization in HTTP/2.
- untitaker_ 4y ago
  >The time to bikeshed whether it's a good idea was at IETF when HTTP/2 has been designed. that's not at all how this works in practice. plenty of bad ideas leave the IETF all the time, and it's up to future standard revisions to follow up with how those are being dealt with in implementations.
- zerocrates 4y ago
  The utility of reuse is clear, but how often is it actually necessary to "reuse" a connection to an address that's not in the DNS for the hostname you're trying to connect to, as here? Seems like it would be very rare.
  - londons_explore 4y ago
    Isn't it fairly common for hundreds of IP's to be in a DNS zone, but only a random subset is returned to the client as a form of basic loadbalancing?
- toast0 4y ago
  > You have to specifically obtain a TLS certificate that contains multiple of your hosts, and their DNS entries have to have at least one IP address in common. But oddly IMHO, the IP used to send requests to both need not be in common?
  - pornel 4y ago
    Yes, because IPs are hard to keep exactly in sync even when they reach the exact same machine, e.g. because of sharding/load-balancing done by CDNs.
zerocrates 4y ago
It seems like it must actually do a DNS lookup to have established the matching IPv6 address, so you're not even saving that. (edit: Or maybe it just ignores DNS totally at this point and operates off having seeing the second hostname in the certificate it got before? That seems like it would cause more issues though.) I'm not sure I totally buy that the spec does allow it (since the "authoritativeness" rules for HTTPS are defined as being in addition to those for HTTP), but beyond that it is a little hard to imagine what purpose there is to be overly-greedy like this in matching up for reused connections.

pornel 4y ago

The time to bikeshed whether it's a good idea was at IETF when HTTP/2 has been designed. This feature has been in production for over 6 years. Note that both hostnames must be in the same TLS certificate. You won't get random hosts coalesced by accident. You have to specifically obtain a TLS certificate that contains multiple of your hosts, and their DNS entries have to have at least one IP address in common. And then the server can still return an HTTP error that tells the browser to stop coalescing and retry with a fresh connection. In practice this feature is commonly used to reuse a single CDN connection to fetch from multiple hosts behind the same CDN (e.g. www.example.com + assets.example.com), and avoids fragmenting per-connection request prioritization in HTTP/2.

untitaker_ 4y ago
>The time to bikeshed whether it's a good idea was at IETF when HTTP/2 has been designed. that's not at all how this works in practice. plenty of bad ideas leave the IETF all the time, and it's up to future standard revisions to follow up with how those are being dealt with in implementations.
zerocrates 4y ago
The utility of reuse is clear, but how often is it actually necessary to "reuse" a connection to an address that's not in the DNS for the hostname you're trying to connect to, as here? Seems like it would be very rare.
- londons_explore 4y ago
  Isn't it fairly common for hundreds of IP's to be in a DNS zone, but only a random subset is returned to the client as a form of basic loadbalancing?
toast0 4y ago
> You have to specifically obtain a TLS certificate that contains multiple of your hosts, and their DNS entries have to have at least one IP address in common. But oddly IMHO, the IP used to send requests to both need not be in common?
- pornel 4y ago
  Yes, because IPs are hard to keep exactly in sync even when they reach the exact same machine, e.g. because of sharding/load-balancing done by CDNs.

zerocrates 4y ago

It seems like it must actually do a DNS lookup to have established the matching IPv6 address, so you're not even saving that. (edit: Or maybe it just ignores DNS totally at this point and operates off having seeing the second hostname in the certificate it got before? That seems like it would cause more issues though.) I'm not sure I totally buy that the spec does allow it (since the "authoritativeness" rules for HTTPS are defined as being in addition to those for HTTP), but beyond that it is a little hard to imagine what purpose there is to be overly-greedy like this in matching up for reused connections.