Re: HTTP 2.0 "Upgrade" flow
"Adrien W. de Croy" <adrien@qbik.com> Wed, 17 April 2013 05:01 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 1CAA021F97BD for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 16 Apr 2013 22:01:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 hsKNlW6zXU0M for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 16 Apr 2013 22:01:47 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id DFC1921F97B3 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 16 Apr 2013 22:01:46 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1USKUP-0006Hj-I8 for ietf-http-wg-dist@listhub.w3.org; Wed, 17 Apr 2013 05:01:01 +0000
Resent-Date: Wed, 17 Apr 2013 05:01:01 +0000
Resent-Message-Id: <E1USKUP-0006Hj-I8@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <adrien@qbik.com>) id 1USKUM-0006H0-O9 for ietf-http-wg@listhub.w3.org; Wed, 17 Apr 2013 05:00:58 +0000
Received: from smtp.qbik.com ([210.55.214.35]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <adrien@qbik.com>) id 1USKUE-00022X-Gc for ietf-http-wg@w3.org; Wed, 17 Apr 2013 05:00:57 +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 3530)) with SMTP id <0019653365@smtp.qbik.com>; Wed, 17 Apr 2013 17:00:26 +1200
From: "Adrien W. de Croy" <adrien@qbik.com>
To: Ilya Grigorik <ilya@igvita.com>, Roberto Peon <grmocg@gmail.com>
Cc: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Date: Wed, 17 Apr 2013 05:00:26 +0000
Content-Type: multipart/alternative; boundary="------=_MBEB3FF0D4-CDEC-44B8-912E-77719BF8DC42"
In-Reply-To: <CAKRe7JGk2496QPTZ7POqZtA4e5Gb5zs3BfJMdKveYnrK+LDe3g@mail.gmail.com>
Message-Id: <em352963fa-7040-4466-8bd5-5e480f58e35b@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.8
X-W3C-Hub-Spam-Report: AWL=-3.090, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.702, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1USKUE-00022X-Gc 5a435a40ebd02fa1e29a9bcee080d398
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP 2.0 "Upgrade" flow
Archived-At: <http://www.w3.org/mid/em352963fa-7040-4466-8bd5-5e480f58e35b@bombed>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17280
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 don't understand why the initial HTTP/1.1 request from the client with the Upgrade header wouldn't also contain the client session frame as payload. Or is this because the method may not permit a body? If so, put it encoded into a request header. Adrien ------ Original Message ------ From: "Ilya Grigorik" <ilya@igvita.com> To: "Roberto Peon" <grmocg@gmail.com> Cc: "Gabriel Montenegro" <Gabriel.Montenegro@microsoft.com>; "Ilari Liusvaara" <ilari.liusvaara@elisanet.fi>; "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org> Sent: 17/04/2013 4:03:57 p.m. Subject: Re: HTTP 2.0 "Upgrade" flow >Thanks Gabriel. I think the workflow you outlined makes sense, but a >few wording clarifications.. > > >>>3.2 says: >>>"The server sends the server session header immediately after >>>receiving and validating the client session header." >>> >>>That is not true if the server is the first one talking on the new >>>session (as in the Upgrade scenario). In this case, the server is the >>>first one, and it sends its 101, empty line, and then a SETTINGS >>>frame (aka as the server session header). In this case, the server >>>does not have the need nor the chance to validate the client session >>>header before sending its own. >+1 > >>>I think section 3.2 should be fixed as follows: >>>OLD: >>>After opening a TCP connection and performing either an HTTP/1.1 >>>Upgrade or TLS handshake, the client sends the client session header. >>>The server replies with a server session header. >>> >>>NEW: >>>After opening a TCP connection and performing either an HTTP/1.1 >>>Upgrade or TLS handshake, the client sends the client session header. > >Is the client side of this even necessary in Upgrade case? Two >scenarios: > >a) client is only interested in a single request, but over HTTP 2.0 > > GET + Upgrade >< 101 + SETTINGS + response frames > >There is no reason for client to respond with its own session header >here? It asked for 2.0, it got 2.0, if it got bogus bytes, it can >terminate the connection. > >b) let's assume (a) happens, but client now wants to send another >request in same session.. > > > HEADERS >< response frames > >Once again, there is no reason for client to append its session header >here? It asked for 2.0, it got 2.0, and its continuing to speak 2.0? > >>>OLD: >>>The server sends the server session header immediately after >>>receiving and validating the client session header. >>> >>>NEW: >>>The server sends the server session header (its SETTINGS frame) as >>>the first frame in the new session, per section 3.8.4. >>> >+1 > >>>Section 2.2 could use some work as well: >>> >>>OLD: >>>Once the server returns the 101 response, both the client and the >>>server send a session header (Section 3.2). >>> >>>NEW: >>>Per section 3.8.4, the first of these HTTP/2.0 frames sent by the >>>server is its SETTINGS frame (which also constitutes the server >>>session header). Upon receiving the 101 response, the client sends >>>its session header (Section 3.2). > >As per comments above, not sure we need the second sentence? The client >session header is required for TLS case, and "naked" (clear text, no >Upgrade) case on port 80. I think.. > >ig
- HTTP 2.0 "Upgrade" flow Ilya Grigorik
- Re: HTTP 2.0 "Upgrade" flow Ilari Liusvaara
- Re: HTTP 2.0 "Upgrade" flow Ilya Grigorik
- RE: HTTP 2.0 "Upgrade" flow Gabriel Montenegro
- Re: HTTP 2.0 "Upgrade" flow Roberto Peon
- Re: HTTP 2.0 "Upgrade" flow Ilya Grigorik
- Re: HTTP 2.0 "Upgrade" flow Roberto Peon
- Re: HTTP 2.0 "Upgrade" flow Adrien W. de Croy
- Re: HTTP 2.0 "Upgrade" flow Roberto Peon
- Re: HTTP 2.0 "Upgrade" flow Amos Jeffries
- Re: HTTP 2.0 "Upgrade" flow Roberto Peon
- Re: HTTP 2.0 "Upgrade" flow Willy Tarreau
- Re: HTTP 2.0 "Upgrade" flow Roberto Peon
- Re: HTTP 2.0 "Upgrade" flow Mark Nottingham
- RE: HTTP 2.0 "Upgrade" flow Gabriel Montenegro
- Re: HTTP 2.0 "Upgrade" flow Martin Thomson
- Re: HTTP 2.0 "Upgrade" flow Martin Thomson
- Re: HTTP 2.0 "Upgrade" flow Adrien W. de Croy
- Re: HTTP 2.0 "Upgrade" flow Martin Thomson
- Re: HTTP 2.0 "Upgrade" flow Adrien W. de Croy
- Re: HTTP 2.0 "Upgrade" flow Martin Thomson
- Re: HTTP 2.0 "Upgrade" flow Adrien W. de Croy
- Re: HTTP 2.0 "Upgrade" flow Adrien W. de Croy
- RE: HTTP 2.0 "Upgrade" flow Gabriel Montenegro
- Re: HTTP 2.0 "Upgrade" flow Adrien W. de Croy