Re: HTTP 2.0 "Upgrade" flow

"Adrien W. de Croy" <adrien@qbik.com> Wed, 17 April 2013 21:42 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 983F821F874A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Apr 2013 14:42:55 -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 MFEopuwozNcq for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Apr 2013 14:42:54 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4884D21F8202 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 17 Apr 2013 14:42:54 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1USa7j-0000tC-Bd for ietf-http-wg-dist@listhub.w3.org; Wed, 17 Apr 2013 21:42:39 +0000
Resent-Date: Wed, 17 Apr 2013 21:42:39 +0000
Resent-Message-Id: <E1USa7j-0000tC-Bd@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 1USa7g-0000sW-Rh for ietf-http-wg@listhub.w3.org; Wed, 17 Apr 2013 21:42:36 +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 1USa7U-0001uU-Jk for ietf-http-wg@w3.org; Wed, 17 Apr 2013 21:42:28 +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 <0019655065@smtp.qbik.com>; Thu, 18 Apr 2013 09:42:01 +1200
From: "Adrien W. de Croy" <adrien@qbik.com>
To: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, 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>
Date: Wed, 17 Apr 2013 21:42:01 +0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; format="flowed"; charset="utf-8"
In-Reply-To: <90099830fdb44516902b45476a184b92@BN1PR03MB072.namprd03.prod.outlook.com>
Message-Id: <emfb65ac6f-f6f7-48bc-abd8-0b9e9f7b8cda@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.162, RP_MATCHES_RCVD=-0.556, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1USa7U-0001uU-Jk 5f5572367da2fb043b50c630abfbe4a5
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP 2.0 "Upgrade" flow
Archived-At: <http://www.w3.org/mid/emfb65ac6f-f6f7-48bc-abd8-0b9e9f7b8cda@bombed>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17303
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 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).
>
>