Re: #385: HTTP2 Upgrade / Negotiation

On 24.10.2012 05:50, James M Snell wrote:
> On Mon, Oct 22, 2012 at 7:03 PM, Mark Nottingham <mnot@mnot.net> 
> wrote:
>
>> [snip]
>>
>> 1) Using a SRV (or other DNS) record. There seems to be a fair 
>> amount of
>> interest in this from the browser implementers; the only resistance 
>> seems
>> to be around how hard this would be to deploy, but if it's not the 
>> only
>> mechanism for upgrading to HTTP/2, it shouldn't be a concern.
>>
>> Presumably, we'd define a default port for HTTP/2-only communication 
>> when
>> used in conjunction with this, so that firewalls would know to open 
>> it, etc.
>>
>>
> Such a dedicated default port definitely needs to be defined. There 
> are
> many scenarios where upgrade negotiation simply is not going to be 
> required
> at all.
>

My understanding of the charter was that defining a new scheme was out 
of bounds. A *default* port would mean a new scheme name was mandatory 
to identify default http://*:80 from default http://*:443 from default 
http2 port.

I find it highly undesirable either way. Lets make HTTP/2 the successor 
to merge both HTTP/1.1 port 80 and HTTP/1.1 port 443 safely with scheme 
http:// and default port 80. Note that this does not require it being 
ASCII text initial request. We can easily and safely prefix with a 
TLS-follows frame to determine HTTPS over port 80.

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

+1 on that.

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

Maybe yes maybe no. This seems to me to be a repetition of the Via: 
header with its path version hints. Equally valid in HTTP/1.a and 2.0 
and covers this use-case already.

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

*except* for all those cases where middleware exists. In which case DNS 
hinting will be the cause of problems, not the solution.

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

That said, how prevalent is first-contact PUT/POST as opposed to a page 
GET followed by further interaction from scripts and forms?
  Is it just from badly designed sites using cross-domain PUT/POST?
  or from non-browser agents which should be able to know better anyway 
with less critical timing requirements?

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

+1.

Also note that the new Expect token needs to be defined as hop-by-hop 
to prevent its relay.

This is also just as useful for Upgrade:HTTP/1.1 to mandate HTTP/1.1 
feature support on the connection.


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

Consider whether you are making HTTP/2 an second protocol to exist in 
parallel to HTTP/1 or a replacement version of the protocol.

A parallel protocol would have a separate scheme (eg. HTTP vs HTTPS 
today). And may as well be called HTTP2/1.1 or "HTTP/1.1 over port 1234" 
as HTTP/2.0.

A replacement would use the same scheme and let the agents negotiate 
the version level between themselves without the web developers getting 
involved with specific URL versions.

Also, how would one go about re-writing the entire legacy web page set 
to use http2:// URLs when the server (or even just its frontend proxy!) 
upgrades?


Amos

Received on Wednesday, 24 October 2012 01:23:52 UTC