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.
>
>
>> 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.

It works in practice. Alternate-Protocol is deployed and live. I'm not
terribly excited about it, since I'd rather people use https:// with
whatever negotiation scheme the TLS WG comes up with.

>
>
>>  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.

I agree with Mark.

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

Received on Wednesday, 24 October 2012 03:58:14 UTC