http - http2 实现中的 PRI 方法导致问题

Question

我正在尝试使用 HTTP/2 扩展服务器，该服务器已经支持 HTTP/1.1 和 TLS v1.2。我在 Go 中编写它，我在其中定义了这样的 tls 配置 -

tlsConfig := &tls.Config{
                    Certificates: []tls.Certificate{cert},
                    ServerName:   "mysrvr",
                    NextProtos:   []string{"h2", "http/1.1", "http/1.0"},
                    Time:         time.Now,
                    Rand:         rand.Reader,
            }

很明显，我使用了“h2”字符串来设置 ALPN 握手。

现在当我通过 curl 发出请求时，我收到了这个请求 -

$ curl -v https://127.0.0.1:8000 -k --http2

当我解析请求时，它显示首先发送的是 PRI 方法，而不是 GET -

HTTP/2.0
PRI

我从https://www.rfc-editor.org/rfc/rfc7540#page-78 得到一些关于PRI 方法的想法|其中它说了以下内容-

This method is never used by an actual client.
This method will appear to be used when an HTTP/1.1 server or
intermediary attempts to parse an HTTP/2 connection preface. 

我现在的问题是，为什么发送 PRI 请求，而服务器显然支持 HTTP/2？我是否需要根据 HTTP/2 规范解析它并使用空的 SETTINGS 框架进行响应，或者 Go http2 运行时是否应该处理它？<​​/p>

我正在使用 http.ReadRequest 来解析客户端请求，但这似乎不适用于 HTTP/2 请求，即使我忽略了 PRI 请求(如下所示)。

Answer 1

HTTP/2 客户端应该发送的第一条消息是这个 PRI 消息。来自HTTP/2 specification :

In HTTP/2, each endpoint is required to send a connection preface as a final confirmation of the protocol in use and to establish the initial settings for the HTTP/2 connection. The client and server each send a different connection preface.

The client connection preface starts with a sequence of 24 octets, which in hex notation is:

0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a

That is, the connection preface starts with the string PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n). This sequence MUST be followed by a SETTINGS frame (Section 6.5), which MAY be empty.

...

Note: The client connection preface is selected so that a large proportion of HTTP/1.1 or HTTP/1.0 servers and intermediaries do not attempt to process further frames.

这条消息的要点是它是一个类似 HTTP/1 的虚假消息，因此任何不支持 HTTP/2 的服务器都应该以错误响应。

任何 HTTP/2 服务器都应该期待这个消息被发送，然后应该忽略它，继续使用 HTTP/2。

事实上，如果这条消息没有被发送，那么服务器应该将其视为一个错误并且不会继续:

Clients and servers MUST treat an invalid connection preface as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. A GOAWAY frame (Section 6.8) MAY be omitted in this case, since an invalid preface indicates that the peer is not using HTTP/2.