Re: HTTP 2.0 "Upgrade" flow

Hi
------ Original Message ------
From: "Martin Thomson" <martin.thomson@gmail.com>
To: "Adrien W. de Croy" <adrien@qbik.com>
Cc: "Gabriel Montenegro" <Gabriel.Montenegro@microsoft.com>; "Mark 
Nottingham" <mnot@mnot.net>; "Ilari Liusvaara" 
<ilari.liusvaara@elisanet.fi>; "Ilya Grigorik" <ilya@igvita.com>; 
"ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Sent: 18/04/2013 10:11:06 a.m.
Subject: Re: HTTP 2.0 "Upgrade" flow
>I think that you either send the session header immediately after the
>first request (the Upgrade) and risk having it swalled,
that could do nasty things if the server is only 1.1
>or you send it
>immediately before the next (HTTP/2.0) request. In either case, you
>don't incur an RTT delay.
next request may not exist.
Adrien
>
>If you thought that the server would wait for the client session
>header before sending its SETTINGS, then I don't think that was every
>the intention (the recent edits from Gabriel fix that problem, I
>hope). That would add an RTT and we don't want that.
>
>On 17 April 2013 15:07, Adrien W. de Croy <adrien@qbik.com> wrote:
>>
>> my main concern is what does a forward proxy do.
>>
>> the client may choose to maintain a database of known http2 capable 
>>servers.
>> This may be too much of a burden for the proxy.
>>
>> Discovery at the proxy could be a bit of a burden as well.
>>
>> A proxy offering 2.0 support to 2.0 clients but still having to talk 
>>to the
>> great unwashed internet has quite a dilemma. The safe/lazy/whatever 
>>option
>> for the proxy may be to always use the Upgrade option. Adding a RTT 
>>in this
>> case will be seen by clients/customers as a performance degradation 
>>in many
>> cases.
>>
>> Or maybe I've not thought this through properly.
>>
>>
>> Adrien
>>
>>
>> ------ Original Message ------
>> From: "Martin Thomson" <martin.thomson@gmail.com>
>> To: "Adrien W. de Croy" <adrien@qbik.com>
>> Cc: "Gabriel Montenegro" <Gabriel.Montenegro@microsoft.com>; "Mark
>> Nottingham" <mnot@mnot.net>; "Ilari Liusvaara"
>> <ilari.liusvaara@elisanet.fi>; "Ilya Grigorik" <ilya@igvita.com>;
>> "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
>> Sent: 18/04/2013 10:00:47 a.m.
>> Subject: Re: HTTP 2.0 "Upgrade" flow
>>>
>>> So you intend to make client SETTINGS available to the server prior 
>>>to
>>> the server commencing transmission. This is the essence of what
>>> Gabriel intends with his known state proposal. He is concerned by 
>>>the
>>> asymmetry of the exchange when Upgrade is involved (as opposed to 
>>>the
>>> TLS session startup). You should talk to Gabriel.
>>>
>>> On 17 April 2013 14:56, Adrien W. de Croy <adrien@qbik.com> wrote:
>>>>
>>>>
>>>> I think it would need to go in as a header. Maybe even as an 
>>>>attribute
>>>> to
>>>> the Upgrade? Not sure if that supports such things. E.g.
>>>>
>>>> GET /bob.txt HTTP/1.1
>>>> Host: somewhere.co.nz
>>>> Upgrade: HTTP/2.0 ; session=[......]
>>>>
>>>> so that the server can respond with the resource in any case.
>>>>
>>>> Adding a RTT to all HTTP 2.0 connections I thought had been 
>>>>decided was
>>>> a
>>>> non-starter. Or compared to TLS setup phase + NPN maybe it's no 
>>>>worse.
>>>>
>>>>
>>>> Adrien
>>>>
>>>>
>>>> ------ Original Message ------
>>>> From: "Martin Thomson" <martin.thomson@gmail.com>
>>>> To: "Adrien W. de Croy" <adrien@qbik.com>
>>>> Cc: "Gabriel Montenegro" <Gabriel.Montenegro@microsoft.com>; "Mark
>>>> Nottingham" <mnot@mnot.net>; "Ilari Liusvaara"
>>>> <ilari.liusvaara@elisanet.fi>; "Ilya Grigorik" <ilya@igvita.com>;
>>>> "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
>>>> Sent: 18/04/2013 9:51:47 a.m.
>>>> Subject: Re: HTTP 2.0 "Upgrade" flow
>>>>>
>>>>>
>>>>> It's possible that the client could pipeline the session header, 
>>>>>but
>>>>>
>>>>> that does stand a chance of being subsumed into the initial 
>>>>>request.
>>>>> I expect packet-based hacks.
>>>>>
>>>>> On 17 April 2013 14:42, Adrien W. de Croy <adrien@qbik.com> 
>>>>>wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> My understanding was that we would not be sacrificing the first
>>>>>> request
>>>>>> due
>>>>>> to a requirement to upgrade.
>>>>>>
>>>>>> In order for the server to send an actual response, if it needs 
>>>>>>the
>>>>>> client
>>>>>> session header, this should be sent in the initial request 
>>>>>>which
>>>>>> includes
>>>>>> the upgrade.
>>>>>>
>>>>>> Otherwise we just added a RTT
>>>>>>
>>>>>>
>>>>>> Adrien
>>>>>>
>>>>>>
>>>>>> ------ Original Message ------
>>>>>> From: "Gabriel Montenegro" <Gabriel.Montenegro@microsoft.com>
>>>>>> To: "Mark Nottingham" <mnot@mnot.net>
>>>>>> Cc: "Ilari Liusvaara" <ilari.liusvaara@elisanet.fi>; "Ilya 
>>>>>>Grigorik"
>>>>>> <ilya@igvita.com>; "ietf-http-wg@w3.org Group" 
>>>>>><ietf-http-wg@w3.org>
>>>>>> Sent: 18/04/2013 5:02:01 a.m.
>>>>>> Subject: RE: HTTP 2.0 "Upgrade" flow
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Personally, I'm not thrilled with how the server session 
>>>>>>>>header is
>>>>>>>> conflated
>>>>>>>> with a SETTINGS frame... if we're going to require that the 
>>>>>>>>server
>>>>>>>> send
>>>>>>>> a
>>>>>>>> SETTINGS frame first (which is fine), let's just come out 
>>>>>>>>and say
>>>>>>>> that,
>>>>>>>> rather
>>>>>>>> than making it a side effect of requiring a (largely 
>>>>>>>>fictional)
>>>>>>>> server
>>>>>>>> session
>>>>>>>> header.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The spec already says that in section 3.8.4 that a SETTINGS 
>>>>>>>frame
>>>>>>> MUST
>>>>>>> be
>>>>>>> the first frame sent by either party in a new session.
>>>>>>>
>>>>>>> So that part is fine. If we wish to say that a server has no 
>>>>>>>session
>>>>>>> header, that would be fine.
>>>>>>>
>>>>>>> As for " As proposed by Gabriel, SETTINGS (or equivalent)
>>>>>>> would/could
>>>>>>> be
>>>>>>> carried in the headers in the UPGRADE request."
>>>>>>>
>>>>>>> For the record, I did not say that in the Upgrade scenario the
>>>>>>> client
>>>>>>> session header is sent in HTTP/1.1 along with the Upgrade 
>>>>>>>request.
>>>>>>> My
>>>>>>> understanding is that the Upgrade request goes without the 
>>>>>>>client
>>>>>>> session
>>>>>>> header. As we have discussed in Orlando, we could add some 
>>>>>>>HTTP/1.1
>>>>>>> headers
>>>>>>> to address the known state by conveying *some* of the settings 
>>>>>>>(only
>>>>>>> those
>>>>>>> absolutely necessary to achieve known initial state). But 
>>>>>>>that's a
>>>>>>> separate
>>>>>>> proposal/discussion from this thread.
>>>>>>>
>>>>>>> At any rate, the server sends back the 101, and begins its 
>>>>>>>HTTP/2.0
>>>>>>> traffic by sending its SETTINGS frame and its response frames, 
>>>>>>>and
>>>>>>> the
>>>>>>> client upon receiving the 101, and only then, begins sending
>>>>>>> HTTP/2.0
>>>>>>> traffic starting with its client session header (which 
>>>>>>>includes the
>>>>>>> magic
>>>>>>> sequence and the client SETTINGS frame).
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>

Received on Wednesday, 17 April 2013 22:37:18 UTC

AltStyle によって変換されたページ (->オリジナル) /