Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
MIME-Version: 1.0
In-Reply-To: <B388B626-2EC2-4F67-B418-98F8DF8D3968@greenbytes.de>
References: <20160419144710.Horde.fEyz_FnLQe5b-8glHPB0ySG@webmail.michael-kaufmann.ch>
 <CACsi252Zc8SqBbW+gPUngUiZWX9gV6P0KRNQEj0ooQ6ebHS0wQ@mail.gmail.com>
 <CE051216-EAA0-4ED5-8132-90EEF2BB021A@greenbytes.de> <CACsi251ncQCkB+dM-Gd9k4HP8uppo+5Ke+DPxAAhh99a6kN8iA@mail.gmail.com>
 <20160609225218.Horde.El_vB3E_HAGC8AX_DHoPc1R@webmail.michael-kaufmann.ch>
 <CACsi25341fFid-yTu31H369qQdCnUp7Ti1V+T5iPm3iksZO=Xw@mail.gmail.com> <B388B626-2EC2-4F67-B418-98F8DF8D3968@greenbytes.de>
From: William A Rowe Jr <wrowe@rowe-clan.net>
Date: Fri, 10 Jun 2016 09:22:55 -0500
Message-ID: <CACsi251E_DoG-xoHL-Y5bKFWwNouDGZYbadyemB2TCfFbNUH6g@mail.gmail.com>
Subject: Re: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)
To: httpd <dev@httpd.apache.org>
Content-Type: multipart/alternative; boundary=001a1145a8506766c70534ed468f
archived-at: Fri, 10 Jun 2016 14:23:03 -0000

--001a1145a8506766c70534ed468f
Content-Type: text/plain; charset=UTF-8

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.

--001a1145a8506766c70534ed468f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Jun 10, 2016 at 4:03 AM, Stefan Eissing <span dir=3D"ltr">&lt;<a href=
=3D"mailto:stefan.eissing@greenbytes.de" target=3D"_blank">stefan.eissing@g=
reenbytes.de</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:soli=
d;border-left-color:rgb(204,204,204);padding-left:1ex">Withdrawn the propos=
al in r1747668 after reading the comment from Roy again.<br></blockquote><d=
iv><br></div><div>Let&#39;s look at what Roy said... that httpd&#39;s imple=
mentation of HTTP/1.1 may choose</div><div>to honor a Connection-Upgrade re=
quest header of h2, or http/2, or any other values</div><div>we choose, bec=
ause we are bound by the HTTP/1.1 RFC, not some arbitrary choice</div><div>=
by the HTTP/2 RFC. Wrong RFC to change HTTP/1.1 behavior, these headers are=
</div><div>only to be used in conformance with <a href=3D"https://tools.iet=
f.org/html/rfc7230#section-6.7">https://tools.ietf.org/html/rfc7230#section=
-6.7</a></div><div><br></div><div>So the http/1.1 Upgrade response header m=
ust mirror what the server will honor</div><div>for the Connection: Upgrade=
 =C2=A0http/1.1 -&gt; {something else} Upgrade=C2=A0request=C2=A0value.</di=
v><div><br></div><div>My initial response is still correct, *if* httpd is w=
illing to honor Upgrade: h2</div><div>or Upgrade: http/2 request header val=
ues, then it is appropriate to offer these</div><div>in the response header=
s. And as Roy says, we *can* do so irrespective of</div><div>any claims wit=
hin=C2=A0<a href=3D"https://tools.ietf.org/html/rfc7540#section-3.2">https:=
//tools.ietf.org/html/rfc7540#section-3.2</a> because that</div><div>is not=
 the binding specification during the http/1.1 phase of the request.</div><=
div><br></div><div><a href=3D"https://tools.ietf.org/html/rfc7540#page-78">=
https://tools.ietf.org/html/rfc7540#page-78</a> registered the h2c token fo=
r the<br></div><div>Upgrade token, HTTP (including HTTP/2) was already regi=
stered. However,</div><div>no token &#39;h2&#39; is registered. That doesn&=
#39;t prevent us or others from sending=C2=A0</div><div>and respecting othe=
r values, SSL/ was long considered valid, but I don&#39;t</div><div>see whe=
re &#39;h2&#39; should be used in the context of the &#39;Upgrade&#39; head=
er.</div><div><a href=3D"http://www.iana.org/assignments/http-upgrade-token=
s/http-upgrade-tokens.xhtml">http://www.iana.org/assignments/http-upgrade-t=
okens/http-upgrade-tokens.xhtml</a><br></div><div><br></div><div>For right =
now, &#39;h2&#39; should not be presented if &#39;h2&#39; will not be honor=
ed, IMHO.</div></div></div></div>

--001a1145a8506766c70534ed468f--