Re: h2 use of Upgrade

Roy--
Assuming that we went with upgrade as you specify, and we needed to specify
a different profile (e.g. HTTP2 but with lower default limits on the
various settings), how would that be negotiated?

-=R


On Wed, Sep 3, 2014 at 2:08 PM, Roy T. Fielding <fielding@gbiv.com> wrote:

> On Sep 2, 2014, at 11:03 PM, Mark Nottingham wrote:
> > On 1 Sep 2014, at 6:16 am, Roy T. Fielding <fielding@gbiv.com> wrote:
> >
> >> This comment is in reference to section 3.2 of
> >>
> >> http://tools.ietf.org/id/draft-ietf-httpbis-http2-14.txt
> >>
> >>> 3.2.  Starting HTTP/2 for "http" URIs
> >>>
> >>>  A client that makes a request to an "http" URI without prior
> >>>  knowledge about support for HTTP/2 uses the HTTP Upgrade mechanism
> >>>  (Section 6.7 of [RFC7230]).  The client makes an HTTP/1.1 request
> >>>  that includes an Upgrade header field identifying HTTP/2 with the
> >>>  "h2c" token.  The HTTP/1.1 request MUST include exactly one
> >>>  HTTP2-Settings (Section 3.2.1) header field.
> >>>
> >>>  For example:
> >>>
> >>>    GET / HTTP/1.1
> >>>    Host: server.example.com
> >>>    Connection: Upgrade, HTTP2-Settings
> >>>    Upgrade: h2c
> >>>    HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>
> >>
> >> The protocol-name is HTTP and the protocol-version is 2, so the correct
> >> upgrade protocol is HTTP/2 and the correct HTTP/1.1 response is
> >>
> >>    GET / HTTP/1.1
> >>    Host: server.example.com
> >>    Connection: Upgrade, HTTP2-Settings
> >>    Upgrade: HTTP/2
> >>    HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>
> >>
> >> That is, unless we want to change the name of this protocol to h2c
> >> (seems unlikely given the rest of the text).
> >
> > This was always going to be a bit of a hack, because HTTP/1 and TLS each
> has their own name space to identify the protocol to be spoken.
> >
> > We chose to use the ALPN token because that’s the primary way to
> indicate breaking changes in HTTP/2, so future revisions (or variants)
> would presumably do the same thing. Given that the HTTP protocol name space
> is pretty static and small, that seemed like a reasonable thing to do.
>
> I don't see the point.  The protocol name is HTTP.  HTTP/1.1 is what you
> are sending in this message, and HTTP/1.1 says that the protocol name is
> HTTP.  It even uses HTTP/2.0 in the examples.
>
> > Re-reading 7230 here, there isn’t a lot of semantic heft in the
> protocol-identifier. I think the most you can say is that we’re wilfully
> not reusing the existing “HTTP” protocol-name, and choosing not to use the
> (optional) protocol-version; instead, we’re choosing to align with ALPN, so
> that this revision (and future ones) don’t have to define both an ALPN
> token as well as a HTTP protocol-version.
> >
> > Does doing so cause problems?
>
> Yes, it contradicts RFC7230, which is a bad example to be setting.
> Unless there is a strong reason to do so, and I have seen none here,
> then the right choice is to follow the HTTP/1.1 design as intended.
> Note also that
>
>   Upgrade: TLS, HTTP/2
>
> is already defined to mean: upgrade the connection to some version of
> TLS and HTTP/2 at the same time.
>
> ....Roy
>
>
>