W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: HTTP 2.0 "Upgrade" flow

From: Adrien W. de Croy <adrien@qbik.com>
Date: Wed, 17 Apr 2013 21:42:01 +0000
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>
Message-Id: <emfb65ac6f-f6f7-48bc-abd8-0b9e9f7b8cda@bombed>

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" <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 
>>  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 21:42:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:10 UTC