- 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>
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). > >
Received on Wednesday, 17 April 2013 21:42:36 UTC