Re: same connection, different hosts

I pretty much concluded that, based on the way our server infrastructure
works, we should set no-cache headers with all 421 responses.

This seems a reasonable option for any deployment where virtual servers
wander around behind different clusters of proxies. Sometimes it's an
optimization where you want to redirect requests for certain resources to
somewhere closer to the client or to a server that already has the
resources required cached locally.

In point of fact, I'm not sure there are any circumstances that you'd want
clients to cache a 421. Because clearly you've configured DNS such that
both hosts go to the same IP, therefore there must be (barring
misconfiguration) a new connection scenario where it's okay to send
requests for the 421 rejected host to the IP.

Perhaps there's an ALT-SVC case where caching 421's makes sense, I haven't
really thought about it.


On Fri, May 29, 2015 at 10:57 PM, Amos Jeffries <squid3@treenet.co.nz>
wrote:

> 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
>
>
>