Re: HTTP 2.0 "Upgrade" flow

"Adrien W. de Croy" <adrien@qbik.com> Wed, 17 April 2013 21:57 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 F025821E80A9 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Apr 2013 14:57:25 -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 Xz4IA+p0Zs+o for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Apr 2013 14:57:25 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3801F1F0D10 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 17 Apr 2013 14:57:25 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1USaLR-0000Cz-Mm for ietf-http-wg-dist@listhub.w3.org; Wed, 17 Apr 2013 21:56:49 +0000
Resent-Date: Wed, 17 Apr 2013 21:56:49 +0000
Resent-Message-Id: <E1USaLR-0000Cz-Mm@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 1USaLP-0000CK-26 for ietf-http-wg@listhub.w3.org; Wed, 17 Apr 2013 21:56:47 +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 1USaLN-0002Fq-VU for ietf-http-wg@w3.org; Wed, 17 Apr 2013 21:56:47 +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 <0019655091@smtp.qbik.com>; Thu, 18 Apr 2013 09:56:23 +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 21:56:23 +0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; format=flowed; charset=utf-8
In-Reply-To: <CABkgnnVq27RCHs=hCQTr97urQc54pHdMPKQ6+WXwHYxdA_tnkA@mail.gmail.com>
Message-Id: <em7d6e997d-d66e-46d2-a0ac-ba9b205a2a99@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.7
X-W3C-Hub-Spam-Report: AWL=-3.114, RP_MATCHES_RCVD=-0.556, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1USaLN-0002Fq-VU 0012e44288bcf6b61758632afc669f78
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP 2.0 "Upgrade" flow
Archived-At: <http://www.w3.org/mid/em7d6e997d-d66e-46d2-a0ac-ba9b205a2a99@bombed>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17306
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>

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