Re: HTTP 2.0 "Upgrade" flow

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:07:58 UTC