连接 [...] 可以重用于具有多个不同 URI 授权组件的请求 [...] 只要源服务器是权威的 [...]。
因此，例如，如果同一个源服务器可以为 foo.example.com 和 bar.example.com 提供服务，那么客户端可以重用一个连接来向两个目的地发出请求。如果不希望这样做，同一部分会说
不希望客户端重用连接的服务器可以通过发送 421（错误定向请求）状态代码来响应请求来表明它对请求不具有权威性 [...]。
这可能会在一些意外情况下出现，例如当使用虚拟服务器并且它们的 TLS 配置不同但它们使用通配符或主题替代名称共享证书时。
不幸的是，最终结果是一个或多个额外的往返：客户端乐观地重用连接，服务器拒绝请求，然后客户端必须打开一个新连接并重试。在最坏的情况下，这可能与仅使用 HTTP/1.1 连接而不重用一样糟糕，甚至更糟糕。当同一个源服务器共享许多不同的目的地并由同一个客户端搜索时，这似乎变得特别糟糕，因为每次打开一个新连接以响应 421 时，客户端仍然觉得它可以重用该连接，并且因此 421 的发生频率几乎与有用的响应一样频繁。
假设根本问题是棘手的，或者至少发送 421 响应的条件超出了服务器管理员的控制范围，但它会发生的事实是已知的，有没有办法提前通知客户端不要重用跨域连接？这仍然留下了 HTTP/2 连接重用的主要好处，即对同一域的多个请求可以在单个连接上多路复用，同时还避免了可预见的 421 响应。