Re: HTTP 1.1 --> 2.0 Upgrade

Hi there,

I like the Patrick analysis as it tries to cover all the different 
aspects of the issue.

for Case 1 - NPN based, the major issue I see is the lack of progress  
the proposal is doing within the TLS wg
                   (note I may be wrong as I don't follow so closely the 
TLS wg)

for Case 2 - it is interesting to see a proposal based on DNS SRV. is 
that a too optimistic one,
                    also due to the fact that browser are not really 
supporting (is this still true?) SRV at moment?

having said that, I am with Greg and Willy about the fact that Upgrade 
is the way to go,
also because that was the main reason why Upgrade was defined at the time.
However I am open and eager to investigate optimization.

So to summarize I support 3b but open to discuss about 3a

/Sal

-- 
Salvatore Loreto, PhD
www.sloreto.com




On 10/1/12 8:03 PM, Willy Tarreau wrote:
> Hi Greg,
>
> On Mon, Oct 01, 2012 at 09:49:42AM -0700, Greg Wilkins wrote:
>> Patrick,
>>
>> this is a good analysis, but my main quibble is that case 3b should be
>> renumbered to be case 0
>>
>> Connecting to port 80 and upgrading to the protocol/version that you
>> want to use should be the basically defined way that a http semantic
>> connection is established, regardless of wire protocol and version
>> used.  All other mechanisms (NPN on 443, DNS SRV, cached redirection
>> to known HTTP/2.0 ports) should all be considered as optimisations of
>> the basic case.
>>
>> Saving round trips is important and I'm all for optimisations for that
>> - but I think it is a MUST that HTTP/2.0 will work in an environment
>> where there is only port 80 and the ability to make a single
>> connection.
>>
>> So I guess that means I support both  3a and 3b.
>>
>> cheers
>>
>> PS.  Does upgrade really mean an extra round trip?  Can't we pipeline
>> HTTP/2.0 request behind the upgrade request if we are confident of
>> success?
> There are possibilities for this that we discussed in the network-friendly
> draft, basically pass a few URIs in a dedicated header field that the server
> is free to consider or not.
>
> Willy
>
>
>

Received on Thursday, 4 October 2012 07:33:06 UTC