Re: HTTP 2.0 "Upgrade" flow
Roberto Peon <grmocg@gmail.com> Wed, 17 April 2013 01:13 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 C01BF21F95F7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 16 Apr 2013 18:13:58 -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=[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 y2DqLvk5EL4y for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 16 Apr 2013 18:13:57 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 53AC121F95E1 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 16 Apr 2013 18:13:57 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1USGwL-0005tn-EF for ietf-http-wg-dist@listhub.w3.org; Wed, 17 Apr 2013 01:13:37 +0000
Resent-Date: Wed, 17 Apr 2013 01:13:37 +0000
Resent-Message-Id: <E1USGwL-0005tn-EF@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1USGwI-0005sy-Dv for ietf-http-wg@listhub.w3.org; Wed, 17 Apr 2013 01:13:34 +0000
Received: from mail-ob0-f182.google.com ([209.85.214.182]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1USGwH-0008Jt-8B for ietf-http-wg@w3.org; Wed, 17 Apr 2013 01:13:34 +0000
Received: by mail-ob0-f182.google.com with SMTP id dn14so972415obc.41 for <ietf-http-wg@w3.org>; Tue, 16 Apr 2013 18:13:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=KmC8fStue8ycdp1ihzO6vx9ZMdIQBLz16joj6l5Kxsw=; b=eQ9B1Rddc3SmsDoBmzODWUk1k9GVMcODW/+chgAF+vzlwdEYhwYiVJdqq1HP+KRWDl aQFmv8Ct1qR7uw6paLYqHURYLAgeXndZ3tnmGSOyNUaCAunOTECH+SUFzcNDWO3xGRij bPEALBvIAiaH7Kr7RwOYOB2VAQMbJII+mYG9j9lFzdMp5eIcdq85tmPS4vIEGcu3zvDE iOcBOEUc4bS3AxEMu/QtYmAp5lP/gQpzd9DB6H4BOpqYl6sx+5EnADI9RvMZCGw+O1yz meglHNLhcyvci9iamdA6Sk73k1GUE+G9QQ70wzKzvwBzZqu9y2CJy6R/weDE/389FzcI eYxw==
MIME-Version: 1.0
X-Received: by 10.182.52.102 with SMTP id s6mr1655358obo.87.1366161187044; Tue, 16 Apr 2013 18:13:07 -0700 (PDT)
Received: by 10.76.141.83 with HTTP; Tue, 16 Apr 2013 18:13:06 -0700 (PDT)
In-Reply-To: <466ca70e40a648d0a691f550d1bf2e9a@BN1PR03MB072.namprd03.prod.outlook.com>
References: <CAKRe7JEiryo+Z4m2OMLibY2c4Eb5nZjfEMzoaADKNvshohh7eQ@mail.gmail.com> <20130414213939.GA6299@LK-Perkele-VII> <466ca70e40a648d0a691f550d1bf2e9a@BN1PR03MB072.namprd03.prod.outlook.com>
Date: Tue, 16 Apr 2013 18:13:06 -0700
Message-ID: <CAP+FsNetw3_pBeSRqYeOaVh=Au8b5WiTozTksWNgszOv0CCu9w@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
Cc: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, Ilya Grigorik <ilya@igvita.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="14dae939960742883f04da843090"
Received-SPF: pass client-ip=209.85.214.182; envelope-from=grmocg@gmail.com; helo=mail-ob0-f182.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.654, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1USGwH-0008Jt-8B 19c717b10c65293859aad25607a4b6bc
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP 2.0 "Upgrade" flow
Archived-At: <http://www.w3.org/mid/CAP+FsNetw3_pBeSRqYeOaVh=Au8b5WiTozTksWNgszOv0CCu9w@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17274
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>
++ -=R On Tue, Apr 16, 2013 at 6:10 PM, Gabriel Montenegro < Gabriel.Montenegro@microsoft.com> wrote: > > > If the client "knows" that the server is HTTP 2.0 capable (DNS, > previous > > > connection, etc), and wants to skip the HTTP 1.1 Upgrade mechanism and > > send > > > "naked" HTTP 2.0 frames from the start (without TLS), I presume it > should > > > still send the session header? As worded above, the behavior is > undefined. > > > I'm guessing, the answer is yes.. > > > > That's the way I understood it... > > > > And session header in that case tells that HTTP/2.0 is coming, not > HTTP/1.x > > In this case, the behavior is defined in the draft. Section 3.2 talks > about the "prior knowledge" scenario, in which neither an Upgrade nor a TLS > handshake occurs: > > http://http2.github.io/http2-spec/#rfc.section.3.2 > "If starting HTTP/2.0 with prior knowledge, the client session header is > sent upon connection establishment." > > > > How does this work in light of the client/server session headers? Do we > > > skip the client session header and send the server session header, > followed > > > by response frames? Or does the client have to wait to get the 101, and > > > then send the client session header before the connection can proceed? > > > > Of course, client has to wait for server session header or it sends > > something designed to cause things to break... > > However, in the Upgrade scenario, I think the draft is not precise. It > follows from 3.8.4 that a SETTINGS frame MUST be the first frame sent by > either party in a new session. Since the server session header *is* a > SETTINGS frame (section 3.2), it follows that the first thing a server > sends is its server session header. So strictly speaking, the server > session header is not a response to the client session header. It is simply > the first thing the server sends on a new session. In the Upgrade case, the > server's session header goes out before the client's, so it is not a > response. > > 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. > > 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. > > 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. > > 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). > > Thanks, > > Gabriel >
- 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