Re: HTTP 2.0 "Upgrade" flow

Ilya Grigorik <ilya@igvita.com> Wed, 17 April 2013 04:06 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 A5D2221F9796 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 16 Apr 2013 21:06:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.976
X-Spam-Level:
X-Spam-Status: No, score=-9.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 4bHM5uVhNp7F for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 16 Apr 2013 21:06:24 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id A75F121F8E47 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 16 Apr 2013 21:06:24 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1USJcN-0004N0-Sv for ietf-http-wg-dist@listhub.w3.org; Wed, 17 Apr 2013 04:05:11 +0000
Resent-Date: Wed, 17 Apr 2013 04:05:11 +0000
Resent-Message-Id: <E1USJcN-0004N0-Sv@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <ilya@igvita.com>) id 1USJcI-0004MC-ES for ietf-http-wg@listhub.w3.org; Wed, 17 Apr 2013 04:05:06 +0000
Received: from mail-qa0-f43.google.com ([209.85.216.43]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <ilya@igvita.com>) id 1USJcH-0005AQ-Dw for ietf-http-wg@w3.org; Wed, 17 Apr 2013 04:05:06 +0000
Received: by mail-qa0-f43.google.com with SMTP id bs12so1697836qab.16 for <ietf-http-wg@w3.org>; Tue, 16 Apr 2013 21:04:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=XRVvj97rwo9BzcdB45PQN1daXzmUgNKz7+FXLYrs32w=; b=B8yyBuOi4j+LzxyqMbm1ktkIP2LzO7wqroIPKrQBAm7mq+T/yr4hxwl+k3MyOA0U0h LVbMczIRGXhXHfkzl3xqMdI0nNBn9v9rRKqsTMc5Y0psbkVMQ/Uj0aNI/7TaQByUgWfL +tQn+Fgbjv48jB0z2Af0JMW4hhHSwhzh8dbYUanytsaR3N1EDrepq5v4YTjaBGy++UL5 akzrlF3k64QouZOq81GLOiGKhGxUsbkVkwSqcWFXG7UIsNKsC+OxIniik6QwH5b3Mruk JOnCZ2sF5GSI7a/hjoGkMp9umTeBlA0VArKWJW/US8y7Oj8/4fhsWfC7ioNOafh8wL1B hpag==
X-Received: by 10.229.69.24 with SMTP id x24mr1869716qci.16.1366171479585; Tue, 16 Apr 2013 21:04:39 -0700 (PDT)
Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by mx.google.com with ESMTPS id u13sm7039359qac.7.2013.04.16.21.04.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Apr 2013 21:04:38 -0700 (PDT)
Received: by mail-qe0-f50.google.com with SMTP id a11so679487qen.37 for <ietf-http-wg@w3.org>; Tue, 16 Apr 2013 21:04:37 -0700 (PDT)
X-Received: by 10.224.179.202 with SMTP id br10mr5414918qab.83.1366171477459; Tue, 16 Apr 2013 21:04:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.36.66 with HTTP; Tue, 16 Apr 2013 21:03:57 -0700 (PDT)
In-Reply-To: <CAP+FsNetw3_pBeSRqYeOaVh=Au8b5WiTozTksWNgszOv0CCu9w@mail.gmail.com>
References: <CAKRe7JEiryo+Z4m2OMLibY2c4Eb5nZjfEMzoaADKNvshohh7eQ@mail.gmail.com> <20130414213939.GA6299@LK-Perkele-VII> <466ca70e40a648d0a691f550d1bf2e9a@BN1PR03MB072.namprd03.prod.outlook.com> <CAP+FsNetw3_pBeSRqYeOaVh=Au8b5WiTozTksWNgszOv0CCu9w@mail.gmail.com>
From: Ilya Grigorik <ilya@igvita.com>
Date: Tue, 16 Apr 2013 21:03:57 -0700
Message-ID: <CAKRe7JGk2496QPTZ7POqZtA4e5Gb5zs3BfJMdKveYnrK+LDe3g@mail.gmail.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>
Content-Type: multipart/alternative; boundary="485b397dcdb19de72e04da869514"
X-Gm-Message-State: ALoCoQldmAzdVJLDFDWeVS/wN5WFHCoP90tHuuGGZ2yJ+2owvsvQNZIPhgEgSh/dU4HY8dG28v1/
Received-SPF: pass client-ip=209.85.216.43; envelope-from=ilya@igvita.com; helo=mail-qa0-f43.google.com
X-W3C-Hub-Spam-Status: No, score=-3.3
X-W3C-Hub-Spam-Report: AWL=-2.589, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1USJcH-0005AQ-Dw 074aa17965c09fb9e5af68ad912f25f3
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP 2.0 "Upgrade" flow
Archived-At: <http://www.w3.org/mid/CAKRe7JGk2496QPTZ7POqZtA4e5Gb5zs3BfJMdKveYnrK+LDe3g@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17278
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>

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