[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-httpd-dev
Subject:    Re: mod_http2 and rejecting HTTP/1 requests...
From:       Stefan Eissing <stefan.eissing () greenbytes ! de>
Date:       2015-12-10 9:28:32
Message-ID: 62F0BC5B-E7E2-4E14-BCF5-8D29F17660DD () greenbytes ! de
[Download RAW message or body]


> Am 09.12.2015 um 19:06 schrieb William A Rowe Jr <wrowe@rowe-clan.net>:
> 
> I think I know where this author was misguided...
> 
> On Dec 9, 2015 11:19, "William A Rowe Jr" <wrowe@rowe-clan.net> 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


[prev in list] [next in list] [prev in thread] [next in thread]