Re: same connection, different hosts

On 30/05/2015 9:02 a.m., Erik Nygren wrote:
> I have some concerns that in moving from a SHOULD NOT to a MAY, client
> behaviors on connection sharing may be underspecified in ways that make it
> very hard for server operators to avoid degenerate situations.  Sending
> requests for arbitrary host headers down an HTTP/2 connection authenticated
> with a wildcard certificate could be highly problematic in some cases, even
> if the certificate matches.  At a minimum, I'd strongly hope/encourage
> clients to only share connections if both hostnames DNS resolve to
> overlapping IP addresses.  Otherwise you might end up talking to a server
> that wasn't even fully configured for accepting traffic for a given
> hostname or otherwise causing major problems for DNS-based load balancers.
> One aspect that could also be better specified is what clients can/should
> use for caching a 421 response.

That is defined in RFC 7234 section 4. HTTP/2 only seeks to replace RFC
7230 message framing.

> For example, most of {IP, Port, SNI-Sent, Authority, ALPN-Negotiated}
> should be used in the key for any caching of a 421 response.

Adding non-HTTP details to the variant conditions makes it uncacheable.

* HTTP(S) messages have to be capable of travelling over more than one
TCP connection. IP and port are not an option.

* Response messages have to be able to transit over HTTP/1.0 and 1.1
hops where Authority SNI, and ALPN are possibly not available.


Received on Saturday, 30 May 2015 05:57:54 UTC