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.

  • @anx foo.example.com requires the client to supply a certificate for client authentication, bar.example.com does not, and the cert is issued for *.example.com
    – kbolino
    Commented Aug 5, 2019 at 18:21

2 Answers 2


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.


You seem to think that the 421 error is outside the server administrator's control. This is not true. It is entirely due to the server administrator's configuration choices that this occurs.

If you do not wish it to occur, use different TLS certificates in addition to the different TLS configuration for the names which you wish to not share an HTTP/2 connection. Because the connection can only be reused for names on that TLS certificate, not matching means the client must open a new connection.

  • 1
    These configuration choices may be driven by factors outside the administrator's control, such as a requirement for legacy SSL compatibility or client certificate authentication. Your response seems to assume that the server administrator is a certificate authority administrator; it may not be feasible to get new certificates on the fly for every subdomain.
    – kbolino
    Commented Aug 5, 2019 at 18:25
  • @kbolino The reasons for doing so may not be in the administrator's control, but actually configuring the server is the administrator's doing. Commented Aug 5, 2019 at 18:44
  • 1
    Yes, that is true. But the server admin, in this case, is not the one deciding when to send 421. It is the server software (nginx, httpd) that makes that decision. As far as I can tell, there is no way to override that (and it may even be impossible; TLS does not allow the server to request a client certificate after the initial handshake as far as I know).
    – kbolino
    Commented Aug 5, 2019 at 19:00
  • 1
    Yes, but that multiplies the initial effort and the maintenance burden (certs expire). Ten subdomains means ten certs, a hundred subdomains is a hundred certs, and so on. This is an HTTP protocol behavior/limitation, it should IMO be resolved at the HTTP layer not by PKI or DNS. I was hoping there was a better way.
    – kbolino
    Commented Aug 5, 2019 at 19:07
  • 1
    IPv4 addresses are rare and costly. Recommending to eat up all remaining addresses for shared web hosting is just unrealistic. And not everybody has IPv6 connectivity where separate IP addresses are no problem. So I conclude that HTTP2 cannot be used with wildcard certificates. That's sad. So HTTP2 doesn't seem to be the future. Or wildcard certificates are to disappear. Either one.
    – ygoe
    Commented Dec 17, 2020 at 13:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .