Re: HTTP 2.0 "Upgrade" flow

"Adrien W. de Croy" <> Wed, 17 April 2013 21:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 983F821F874A for <>; Wed, 17 Apr 2013 14:42:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MFEopuwozNcq for <>; Wed, 17 Apr 2013 14:42:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4884D21F8202 for <>; Wed, 17 Apr 2013 14:42:54 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1USa7j-0000tC-Bd for; Wed, 17 Apr 2013 21:42:39 +0000
Resent-Date: Wed, 17 Apr 2013 21:42:39 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1USa7g-0000sW-Rh for; Wed, 17 Apr 2013 21:42:36 +0000
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1USa7U-0001uU-Jk for; Wed, 17 Apr 2013 21:42:28 +0000
Received: From [] (unverified []) by SMTP Server [] (WinGate SMTP Receiver v8.0.0 (Build 3531)) with SMTP id <>; Thu, 18 Apr 2013 09:42:01 +1200
From: "Adrien W. de Croy" <>
To: "Gabriel Montenegro" <>, "Mark Nottingham" <>
Cc: "Ilari Liusvaara" <>, "Ilya Grigorik" <>, " Group" <>
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: <>
Message-Id: <emfb65ac6f-f6f7-48bc-abd8-0b9e9f7b8cda@bombed>
Mime-Version: 1.0
Reply-To: "Adrien W. de Croy" <>
User-Agent: eM_Client/5.0.17595.0
Received-SPF: pass client-ip=;;
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: 1USa7U-0001uU-Jk 5f5572367da2fb043b50c630abfbe4a5
Subject: Re: HTTP 2.0 "Upgrade" flow
Archived-At: <>
X-Mailing-List: <> archive/latest/17303
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-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


------ Original Message ------
From: "Gabriel Montenegro" <>
To: "Mark Nottingham" <>
Cc: "Ilari Liusvaara" <>fi>; "Ilya Grigorik" 
<>om>; " Group" <>
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 
>>  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).