httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: mod_http2 and rejecting HTTP/1 requests...
Date Wed, 09 Dec 2015 18:06:33 GMT
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.

The author's guidance was written to h2c applications though, and was
clearly wrong for that negotiation.

Mime
View raw message