http2：421 Misdirected 请求状态代码示例
http2: The 421 Misdirected Request Status Code example
我正在阅读 spec 并试图准确了解 421 可能返回的时间。举了一个例子，我不是很明白
背景
规范建立了允许重用连接的两个条件：
For TCP connections without TLS, this depends on the host having resolved to the same IP address.
和
For https resources, connection reuse additionally depends on having a
certificate that is valid for the host in the URI.
如果连接中使用的证书有多个 subjectAltName 或其中任何一个 subjectAltName 是通配符，则该连接可以重新用于具有列表中主机名的任何请求subjectAltName 或匹配任何通配符。
规范中的具体示例
In some deployments, reusing a connection for multiple origins can
result in requests being directed to the wrong origin server. For
example, TLS termination might be performed by a middlebox that uses
the TLS Server Name Indication (SNI) [TLS-EXT] extension to select an
origin server. This means that it is possible for clients to send
confidential information to servers that might not be the intended
target for the request, even though the server is otherwise
authoritative.
请解释我对这个例子的理解错误的地方：
通过具有域 x.com 的请求建立到中间盒的 https 连接。中间盒的 IP 地址为 1.2.3.4，x.com 解析为该地址。使用 SNI，TLS 握手有 x.com 和中间框 returns 一个对该域有效的证书。此连接上的所有消息都从客户端发送到中间盒或从中间盒发送到客户端。从客户端到中间盒的应用程序级消息由中间盒转发到不同连接上的源。从 origin 到 middlebox 的消息被转发到客户端。如果要重用连接，仅仅满足上面讨论的两个条件是不够的。具体来说，对于域为 y.com 的请求：如果 y.com 解析为 1.2.3.4 并且中间盒具有对 y.com 有效的证书，仍然可能存在问题。因为原始连接使用 x.com 进行了 TLS 握手，并且握手仅在新连接开始时完成，所以无法建立 https 连接来获取 y.com 的证书。因此，客户端错误地将同一连接上的请求发送到 y.com。中间盒拒绝请求，因为与连接关联的证书对 x.com 有效 - 而不是 y.com。 （x.com证书只对x.com有效，y.com证书只对y.com有效。
据我所知，None 个示例将触发 421。
是的，您是正确的，连接需要证书中的 IP 地址和 SAN 字段才有效——没有这些，连接不应被重复使用。
那么什么会触发 421？据我所知，这主要是由于不同的 SSL/TLS 设置。
例如：
假设网站 A (siteA.example.com) 和网站 B (www.example.com) 都在同一个 IP 地址上。假设网站 A 有一个 *.example.com 的通配符证书，而网站 B 有一个特定的证书。可能有以下几个原因：例如，它为不能是通配符证书的主要网站提供 EV 证书。
所以证书A涵盖网站A和网站B。IP地址也是如此。因此，如果您连接到网站 siteA.example.com，然后尝试连接到 www.example.com，那么从技术上讲，根据 HTTP/2 标准，您可以重新使用该连接。但我们不希望这种情况发生，因为我们想使用我们的 EV 证书。所以服务器应该拒绝 421。现在在这个例子中，网络服务器能够区分正确的主机并且具有该主机的有效证书，因此理论上可以在通配符证书下提供正确的内容，而不是发送 421 - 但由于未为该虚拟主机定义通配符证书，因此不应执行此操作。
其他示例包括您是否在不同的主机上设置了不同的密码。例如，站点 A 的 HTTPS 配置超级宽松，因为它不是真正安全的内容，他们甚至想访问旧版浏览器，但站点 B 的配置超级安全，只接受最新的 TLS 版本和强密码。在这里，您显然不希望他们重复使用相同的连接细节。请参阅 here 以获取真实示例。
此外，这只是某些浏览器的问题，具体取决于它们决定连接共享的方式。此页面显示他们每个人在执行此操作时有何不同（至少在撰写此博客时 post 不知道此后发生的任何变化）：https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/
另请注意，这会存在一些错误（例如：https://bugs.chromium.org/p/chromium/issues/detail?id=546991）。最好的建议是：如果您不希望发生连接共享，请使用不同的 IP 地址 and/or 确保证书中没有重叠。
我正在阅读 spec 并试图准确了解 421 可能返回的时间。举了一个例子，我不是很明白
背景
规范建立了允许重用连接的两个条件：
For TCP connections without TLS, this depends on the host having resolved to the same IP address.
和
For https resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI.
如果连接中使用的证书有多个 subjectAltName 或其中任何一个 subjectAltName 是通配符，则该连接可以重新用于具有列表中主机名的任何请求subjectAltName 或匹配任何通配符。
规范中的具体示例
In some deployments, reusing a connection for multiple origins can result in requests being directed to the wrong origin server. For example, TLS termination might be performed by a middlebox that uses the TLS Server Name Indication (SNI) [TLS-EXT] extension to select an origin server. This means that it is possible for clients to send confidential information to servers that might not be the intended target for the request, even though the server is otherwise authoritative.
请解释我对这个例子的理解错误的地方：
通过具有域 x.com 的请求建立到中间盒的 https 连接。中间盒的 IP 地址为 1.2.3.4，x.com 解析为该地址。使用 SNI，TLS 握手有 x.com 和中间框 returns 一个对该域有效的证书。此连接上的所有消息都从客户端发送到中间盒或从中间盒发送到客户端。从客户端到中间盒的应用程序级消息由中间盒转发到不同连接上的源。从 origin 到 middlebox 的消息被转发到客户端。如果要重用连接，仅仅满足上面讨论的两个条件是不够的。具体来说，对于域为 y.com 的请求：如果 y.com 解析为 1.2.3.4 并且中间盒具有对 y.com 有效的证书，仍然可能存在问题。因为原始连接使用 x.com 进行了 TLS 握手，并且握手仅在新连接开始时完成，所以无法建立 https 连接来获取 y.com 的证书。因此，客户端错误地将同一连接上的请求发送到 y.com。中间盒拒绝请求，因为与连接关联的证书对 x.com 有效 - 而不是 y.com。 （x.com证书只对x.com有效，y.com证书只对y.com有效。
None 个示例将触发 421。
是的，您是正确的，连接需要证书中的 IP 地址和 SAN 字段才有效——没有这些，连接不应被重复使用。
那么什么会触发 421？据我所知，这主要是由于不同的 SSL/TLS 设置。
例如： 假设网站 A (siteA.example.com) 和网站 B (www.example.com) 都在同一个 IP 地址上。假设网站 A 有一个 *.example.com 的通配符证书，而网站 B 有一个特定的证书。可能有以下几个原因：例如，它为不能是通配符证书的主要网站提供 EV 证书。
所以证书A涵盖网站A和网站B。IP地址也是如此。因此，如果您连接到网站 siteA.example.com，然后尝试连接到 www.example.com，那么从技术上讲，根据 HTTP/2 标准，您可以重新使用该连接。但我们不希望这种情况发生，因为我们想使用我们的 EV 证书。所以服务器应该拒绝 421。现在在这个例子中，网络服务器能够区分正确的主机并且具有该主机的有效证书，因此理论上可以在通配符证书下提供正确的内容，而不是发送 421 - 但由于未为该虚拟主机定义通配符证书，因此不应执行此操作。
其他示例包括您是否在不同的主机上设置了不同的密码。例如，站点 A 的 HTTPS 配置超级宽松，因为它不是真正安全的内容，他们甚至想访问旧版浏览器，但站点 B 的配置超级安全，只接受最新的 TLS 版本和强密码。在这里，您显然不希望他们重复使用相同的连接细节。请参阅 here 以获取真实示例。
此外，这只是某些浏览器的问题，具体取决于它们决定连接共享的方式。此页面显示他们每个人在执行此操作时有何不同（至少在撰写此博客时 post 不知道此后发生的任何变化）：https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/
另请注意，这会存在一些错误（例如：https://bugs.chromium.org/p/chromium/issues/detail?id=546991）。最好的建议是：如果您不希望发生连接共享，请使用不同的 IP 地址 and/or 确保证书中没有重叠。