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: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)
Date Fri, 10 Jun 2016 14:22:55 GMT
On Fri, Jun 10, 2016 at 4:03 AM, Stefan Eissing <
stefan.eissing@greenbytes.de> wrote:

> Withdrawn the proposal in r1747668 after reading the comment from Roy
> again.
>

Let's look at what Roy said... that httpd's implementation of HTTP/1.1 may
choose
to honor a Connection-Upgrade request header of h2, or http/2, or any other
values
we choose, because we are bound by the HTTP/1.1 RFC, not some arbitrary
choice
by the HTTP/2 RFC. Wrong RFC to change HTTP/1.1 behavior, these headers are
only to be used in conformance with
https://tools.ietf.org/html/rfc7230#section-6.7

So the http/1.1 Upgrade response header must mirror what the server will
honor
for the Connection: Upgrade  http/1.1 -> {something else}
Upgrade request value.

My initial response is still correct, *if* httpd is willing to honor
Upgrade: h2
or Upgrade: http/2 request header values, then it is appropriate to offer
these
in the response headers. And as Roy says, we *can* do so irrespective of
any claims within https://tools.ietf.org/html/rfc7540#section-3.2 because
that
is not the binding specification during the http/1.1 phase of the request.

https://tools.ietf.org/html/rfc7540#page-78 registered the h2c token for the
Upgrade token, HTTP (including HTTP/2) was already registered. However,
no token 'h2' is registered. That doesn't prevent us or others from sending
and respecting other values, SSL/ was long considered valid, but I don't
see where 'h2' should be used in the context of the 'Upgrade' header.
http://www.iana.org/assignments/http-upgrade-tokens/http-upgrade-tokens.xhtml

For right now, 'h2' should not be presented if 'h2' will not be honored,
IMHO.

Mime
View raw message