Re: HTTP 2.0 "Upgrade" flow

"Adrien W. de Croy" <adrien@qbik.com> Wed, 17 April 2013 22:08 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C7F1F0D16 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Apr 2013 15:08:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+rDT9-5Lug2 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Apr 2013 15:08:19 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 61A8C1F0D12 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 17 Apr 2013 15:08:19 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1USaWG-00060M-Ru for ietf-http-wg-dist@listhub.w3.org; Wed, 17 Apr 2013 22:08:00 +0000
Resent-Date: Wed, 17 Apr 2013 22:08:00 +0000
Resent-Message-Id: <E1USaWG-00060M-Ru@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <adrien@qbik.com>) id 1USaWE-0005zh-4V for ietf-http-wg@listhub.w3.org; Wed, 17 Apr 2013 22:07:58 +0000
Received: from smtp.qbik.com ([210.55.214.35]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <adrien@qbik.com>) id 1USaWD-0002gh-0c for ietf-http-wg@w3.org; Wed, 17 Apr 2013 22:07:58 +0000
Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v8.0.0 (Build 3531)) with SMTP id <0019655109@smtp.qbik.com>; Thu, 18 Apr 2013 10:07:34 +1200
From: "Adrien W. de Croy" <adrien@qbik.com>
To: "Martin Thomson" <martin.thomson@gmail.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>
Date: Wed, 17 Apr 2013 22:07:34 +0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; format=flowed; charset=utf-8
In-Reply-To: <CABkgnnV-488_Y_ytuFVkG9NuT0PnBeYS38z1BTQ_wVLT-e-12w@mail.gmail.com>
Message-Id: <em69423ffd-502e-4039-b54f-d6239b733acc@bombed>
Mime-Version: 1.0
Reply-To: "Adrien W. de Croy" <adrien@qbik.com>
User-Agent: eM_Client/5.0.17595.0
Received-SPF: pass client-ip=210.55.214.35; envelope-from=adrien@qbik.com; helo=smtp.qbik.com
X-W3C-Hub-Spam-Status: No, score=-3.6
X-W3C-Hub-Spam-Report: AWL=-3.067, RP_MATCHES_RCVD=-0.556, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1USaWD-0002gh-0c a566d7c452a2f840599d07f7c49b62ce
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP 2.0 "Upgrade" flow
Archived-At: <http://www.w3.org/mid/em69423ffd-502e-4039-b54f-d6239b733acc@bombed>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17309
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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>om>; "Mark 
Nottingham" <mnot@mnot.net>et>; "Ilari Liusvaara" 
<ilari.liusvaara@elisanet.fi>fi>; "Ilya Grigorik" <ilya@igvita.com>om>; 
"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>om>; "Mark
>>  Nottingham" <mnot@mnot.net>et>; "Ilari Liusvaara"
>>  <ilari.liusvaara@elisanet.fi>fi>; "Ilya Grigorik" <ilya@igvita.com>om>;
>>  "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>fi>; "Ilya 
>>>>Grigorik"
>>>>   <ilya@igvita.com>om>; "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).
>>>>>
>>>>>
>>>>
>>>>
>>