Re: HTTP 2.0 "Upgrade" flow
Roberto Peon <grmocg@gmail.com> Wed, 17 April 2013 05:20 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 9E58921F979C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 16 Apr 2013 22:20:38 -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 vHwuJm8Mth04 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 16 Apr 2013 22:20:37 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 39FC021F9762 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 16 Apr 2013 22:20:35 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1USKmD-0004sI-4x for ietf-http-wg-dist@listhub.w3.org; Wed, 17 Apr 2013 05:19:25 +0000
Resent-Date: Wed, 17 Apr 2013 05:19:25 +0000
Resent-Message-Id: <E1USKmD-0004sI-4x@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 1USKm9-0004rc-Vk for ietf-http-wg@listhub.w3.org; Wed, 17 Apr 2013 05:19:22 +0000
Received: from mail-ob0-f178.google.com ([209.85.214.178]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1USKm8-0007sX-Ay for ietf-http-wg@w3.org; Wed, 17 Apr 2013 05:19:21 +0000
Received: by mail-ob0-f178.google.com with SMTP id ni5so1079474obc.23 for <ietf-http-wg@w3.org>; Tue, 16 Apr 2013 22:18:54 -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=kgFtvSEJaV3JdU+thMnZbPBUGc7PdL6WCdR+ayEItG4=; b=vvMHO9dilCaVallFzxEfbzxN2/+M1lE1ZtkNGchGRgewlVPzP3ANi32Jw6rdupmJ/b j7SsAbn2lJYo/EX/U8Y+rvF/K2HBWAjd+LC3yrydi/waIeLQkoZEXzM6SwopUrETWsyL cubwBc/5Zjk4I5WvCGaLeXhGLSs2ApHn8e7nkq/RCjkrLF4/sLP+U1mDfQ7rZsJGP6bP e5+5fxjL0rZ1ggQnSezzyu1/aYcxPs7DgXV4ccqv1uTMbhD5HvfTk0fySBOlZ7KHVBNe 1Zh2yc9rvUEb1lrZx6ZGec+lkkw2cQBovZfEwC7vISGT0z+kr5pMf9BXK+5Go5PY3BOP GuQw==
MIME-Version: 1.0
X-Received: by 10.60.17.105 with SMTP id n9mr1892434oed.64.1366175934287; Tue, 16 Apr 2013 22:18:54 -0700 (PDT)
Received: by 10.76.141.83 with HTTP; Tue, 16 Apr 2013 22:18:54 -0700 (PDT)
In-Reply-To: <em352963fa-7040-4466-8bd5-5e480f58e35b@bombed>
References: <CAKRe7JGk2496QPTZ7POqZtA4e5Gb5zs3BfJMdKveYnrK+LDe3g@mail.gmail.com> <em352963fa-7040-4466-8bd5-5e480f58e35b@bombed>
Date: Tue, 16 Apr 2013 22:18:54 -0700
Message-ID: <CAP+FsNcrChWevfdwNgr0e=GH5xKqLYmTjRkffrdM+HvXFtwL+Q@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: "Adrien W. de Croy" <adrien@qbik.com>
Cc: Ilya Grigorik <ilya@igvita.com>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="089e013c682c4397b004da879f02"
Received-SPF: pass client-ip=209.85.214.178; envelope-from=grmocg@gmail.com; helo=mail-ob0-f178.google.com
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-2.639, 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 1USKm8-0007sX-Ay 3f0f301784a2a79191b2af4515ea837f
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP 2.0 "Upgrade" flow
Archived-At: <http://www.w3.org/mid/CAP+FsNcrChWevfdwNgr0e=GH5xKqLYmTjRkffrdM+HvXFtwL+Q@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17281
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>
As proposed by Gabriel, SETTINGS (or equivalent) would/could be carried in the headers in the UPGRADE request. However, this isn't enough by itself-- you still want to cause transparent proxies to barf when you start speaking HTTP/2 if they're not going to be able to handle it. -=R On Tue, Apr 16, 2013 at 10:00 PM, Adrien W. de Croy <adrien@qbik.com> wrote: > > 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