> Am 09.12.2015 um 19:06 schrieb William A Rowe Jr <[email protected]>: > > I think I know where this author was misguided... > > On Dec 9, 2015 11:19, "William A Rowe Jr" <[email protected]> wrote: > > > > And then I'm reading a really nonsensical comment in this FAQ... > > > > https://http2.github.io/faq/#implementation-questions > > Can I implement HTTP/2 without implementing HTTP/1.1? > > "Requests without the h2c upgrade token can be rejected with a 505 (HTTP > > Version Not Supported) status code that contains the Upgrade header field. > > Servers that don’t wish to process the HTTP/1.1 response should reject > > stream 1 with a REFUSED_STREAM error code immediately after sending the > > connection preface to encourage the client to retry the request over the > > upgraded HTTP/2 connection." > > > > > > which would be absurd... > > > > 6.6.6. 505 HTTP Version Not Supported > > > > The 505 (HTTP Version Not Supported) status code indicates that the > > server does not support, or refuses to support, the major version of > > HTTP that was used in the request message. The server is indicating > > that it is unable or unwilling to complete the request using the same > > major version as the client, as described in Section 2.6 of > > [RFC7230], other than with this error message. The server SHOULD > > generate a representation for the 505 response that describes why > > that version is not supported and what other protocols are supported > > by that server. > > > > A 505 is an unrecoverable error, the client isn't expected to do anything > > with it. > > > > I just want to ensure that we do *not* follow this guidance; if the user > > wants configure httpd to enforce HTTP/2 only on a particular vhost, we > > should be sending a 426 error always, with an error message explaining > > exactly why their request is rejected, but giving the user-agent the > > opportunity to automatically upgrade without presenting the message to the > > user.
> I think the guidance above is correct for TLS h2 or HTTP/1 requests. ALPN > handshake should have resulted in an HTTP/2 connection, so if we are still at > HTTP/1 in a TLS session we can't continue, and it is a fatal 505 condition. If ALPN negotiated h2, the connection is on HTTP/2 semantics. If the client sends some HTTP/1 on it, it will lead to a protocol error and a GOAWAY frame before the connection is shutdown. We cannot send out a HTTP/1 response on a h2 connection. If we have a cleartext connection, it starts in HTTP/1 format (unless we have some totally other Protocol directly configured on it). There are several cases to consider: 1. Protocols something http/1.1 other a) without Upgrade: header, HTTP/1 processing just continues. If it is the first request on a connection, we kindly advise the client about Upgrade possibilities in an Upgrade: response header. b) with Upgrade: header, internal protocol proposing and maybe switching starts, or maybe not. If only "other" is proposed, we would stay on http/1.1, since that is preferred. 2. Protocols something other a) without Upgrade: server answers 426, since it is not configured to stay on HTTP/1 here. Upgrade advisory as above. b) with Upgrade: negotiation as above, success -> switch, nothing agreed -> 505 response, as the protocols suggested by the client were not supported by the server, Upgrade advisory response header. 3. Server receives "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n", which is the h2c direct mode. mod_http2 currently tries to detect this on a new connection, if configured. Currently, this gives a "400 Bad Request", if mod_http2 does not take over. We could change this to a 505 answer. //Stefan
