Disable HTTP/2 connection reuse across domains

kbolino asked:

RFC 7540, § 9.1.1 states that

Connections […] MAY be reused for requests with multiple different URI authority components […] as long as the origin server is authoritative […].

So, for example, if the same origin server can serve foo.example.com and bar.example.com then the client may reuse a connection to issue requests to both destinations. When that’s not desired, the same section says

A server that does not wish clients to reuse connections can indicate that it is not authoritative for a request by sending a 421 (Misdirected Request) status code in response to the request […].

This can arise in some unexpected situations, such as when virtual servers are used and their TLS configuration differs but they share a certificate using wildcards or subject alternative names.

Unfortunately, the end result is one or more extra round trips: the client optimistically reuses a connection, the server rejects the request, and then the client has to open a new connection and try again. In the worst case, this can be as bad as or perhaps even worse than just using HTTP/1.1 connections without reuse. It seems to get especially bad when there are many different destinations shared by the same origin server and sought by the same client, as each time a new connection is opened in response to a 421, the client still feels it can reuse that connection, and so the 421s can happen almost as often as useful responses.

Assuming the underlying problem is intractable, or at least the conditions under which a 421 response is sent are beyond the control of a server administrator, but the fact that it will happen is known, is there a way to inform clients in advance not to reuse connections across domains? This still leaves the primary benefit of HTTP/2 connection reuse, namely that multiple requests to the same domain can be multiplexed on a single connection, while also avoiding foreseeable 421 responses.

My answer:


The nuclear option is to simply put the server needing the special configuration on a separate IP address, so that the browser can’t reuse the connection. If the site is meant to be accessible to the Internet, then it must be a separate global IP address, not a separate RFC1918 address in your local network.


View the full question and any other answers on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.