- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Sat, 30 May 2015 17:57:10 +1200
- To: ietf-http-wg@w3.org
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.
Amos
Received on Saturday, 30 May 2015 05:57:54 UTC