Re: #385: HTTP2 Upgrade / Negotiation

On 10/24/12 4:23 AM, Amos Jeffries wrote:
> 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.

I am not really convinced that defining a *new* default port for 
HTTP/2-only communication is a good idea.



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

+1 on SRV record

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

+1 on the Expected token, it is really useful


/Salvatore

>
>
>>
>> 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 Thursday, 25 October 2012 06:22:10 UTC