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