Re: #385: HTTP2 Upgrade / Negotiation

On Tue, Oct 23, 2012 at 8:44 PM, Mark Nottingham <mnot@mnot.net> wrote:

>
> On 24/10/2012, at 3:50 AM, James M Snell <jasnell@gmail.com> wrote:
>
> [...]
> >>  Does anyone object to us defining such a record (type TBD), as long as
> it's not the only way to get to HTTP/2 for HTTP URIs?
> >
> > Defining a new dns record type would be unnecessary and would be the
> wrong approach. SRV records were made specifically for this kind of use.
> They're certainly not perfect but inventing a new record type specifically
> for http2 stuff is even less so.
>
> We're not talking about defining a new record type, only deciding whether
> DNS is an appropriate OPTIONAL upgrade path, and EVENTUALLY which existing
> record type to use.
>
> Everyone, please focus on the questions at hand -- we don't need to have a
> round of +1s and resulting back-and-forth on an issue that's not even being
> discussed yet.
>
>
Ok.. consider this a proposal then ;-)


>
> > 2) Using a response header to hint that HTTP/2 is available on another
> port.
> >
> > This approach hasn't been talked about in detail yet, but it apparently
> (as some have noted) has the disadvantage of not upgrading the first
> interaction, and of requiring a separate cache (and caching model) for this
> information.
> >
> > Who wants to pursue this approach? If so, we need a small proposal
> written, preferably as an I-D, but an e-mail would do.
> >
> >
> > This is one of those ideas that sounds interesting in theory but I don't
> see how it would be effective in practice.
>
> Yep - that's why I asked for proposals.
>
>
> >  And, are there any other approaches we want to put on the table?
> >
> > For browsers, upgrading on the first connection is obviously going to be
> critical. The DNS option seems like the best approach for the most general
> case, despite the various flaws in that approach.
> montenegro-httpbis-http2-negotiation seems to provide a reasonable fallback
> when we're talking primarily about GET/HEAD traffic, but it has obvious
> issues when dealing with POST/PUT/PATCH type operations. I do not really
> want to always have to send PUT requests as HTTP/1.1 when what I really
> want is to use HTTP/2.0 for the entire flow. For payload-bearing requests,
> upgrade needs to be negotiated before the initial request is sent.
> >
> > One possible way to mitigate this would be to combine the Upgrade header
> approach with a new Expect token. For instance...
> >
> >   POST /default.htm HTTP/1.1
> >   Host: server.example.com
> >   Connection: Upgrade
> >   Upgrade: HTTP/2.0
> >   Expect: 101-upgrade
> >
> > The addition of the Expect header does two things...
> >
> > 1. It makes the upgrade a requirement rather than optional...
> > 2. The client would then wait as reasonable time for the 101 Switching
> Protocols before it proceeds to send the http/2.0 encoded data...
> >
> > When the client does start sending the data (after receiving the 101
> response), it would do so by first sending a SYN_STREAM.. To http/1.1
> servers, this would appear to be nothing more than regular POST payload
> data. For http/2 traffic, this requires an initial round trip but it
> addresses the upgrade on payload-bearing request issue... and is exactly
> the kind of thing the Expect header was intended for. The scheme is
> obviously far from perfect, however.
>
> Hm. I'd be interested to hear from implementers on this. The only
> advantage that I see is that you'd be able to start multiplexing other
> requests on the same connection sooner. However, you could also just use
> SRV, or a different connection if it's not available.
>
>
Well.. the other advantage is that you upgrade before sending payload data,
which is a step up from montenegro-httpbis-http2-negotiation... It's
certainly not without it's problems, however. For my money, however, the
SRV route is preferable but certainly has it's own range of issues.

(and, so we're clear, who exactly do you classify as "implementors" here?)


>
> > Alternatively, I firmly believe that a http2 URI scheme as a reasonable
> fallback needs to be considered as an option here... particularly if we do
> define a dedicated http/2 default port. Yes, I agree with the whole "we
> want to do existing http:// and https:// traffic over http/2
> transparently" argument and fully understand the challenges of introducing
> a new URI scheme. However, there will be instances where upgrade
> negotiation is simply not going to be necessary and for which backwards
> compatibility with existing infrastructure is going to be unnecessary. For
> those cases, the ability to pass a URL like "http2://example.org" and
> have it just automatically understood that it's "http/2 over port whatever"
> will be extremely useful. A no brainer even. So much so that if the working
> group here doesn't choose to define it, I'll likely just end up writing it
> up as an individual submission. That way, when I write.. <form
> method="post" action="http2://example.org">...</form> the notion that
> http/2 is being used is explicit and no upgrade discovery/negotiation is
> required at all. That's what url schemes are for in the first place, right?
>
> I don't see any consensus to do this here; does anyone support James'
> position, or want to discuss it more?
>
>
You're the one who asked for proposals ;-) ... I believe you're also the
one who said, "we don't need to have a round of +1s and resulting
back-and-forth on an issue that's not even being discussed yet." ... I
brought this up as one of several possible proposals for discussion at some
point. I'm not going to argue this particular point of view further right
now but it does need to be recognized that
http2-without-upgrade-negotiation is definitely something that needs to be
considered in-scope.

- James


> (i.e., we've heard enough from folks challenging this approach, for now)
>
> Regards,
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>