Re: HTTP 2.0 "Upgrade" flow

Martin Thomson <martin.thomson@gmail.com> Wed, 17 April 2013 21:33 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 A17A521E80EF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Apr 2013 14:33:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 gVdKESro9yqS for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Apr 2013 14:33:47 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCC621E80EC for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 17 Apr 2013 14:33:47 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1USZyI-0005D9-NA for ietf-http-wg-dist@listhub.w3.org; Wed, 17 Apr 2013 21:32:54 +0000
Resent-Date: Wed, 17 Apr 2013 21:32:54 +0000
Resent-Message-Id: <E1USZyI-0005D9-NA@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1USZyF-0005BR-VR for ietf-http-wg@listhub.w3.org; Wed, 17 Apr 2013 21:32:51 +0000
Received: from mail-wi0-f174.google.com ([209.85.212.174]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1USZyF-000485-9v for ietf-http-wg@w3.org; Wed, 17 Apr 2013 21:32:51 +0000
Received: by mail-wi0-f174.google.com with SMTP id m6so3105641wiv.7 for <ietf-http-wg@w3.org>; Wed, 17 Apr 2013 14:32:25 -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:content-transfer-encoding; bh=7d/q08h24geB0Bl4GUzDnrzQ7TsZyX6wgtvIXOyddD4=; b=pT4t09dowfku5A+Q9lEsJIf1+I01jc6/7RVkhfyVX0H6CN5f+671Vib/G+VGH8ufRM 4SAD/LETx/bWVZX7fTiKFJXrBOYa7QVA/HLxS5VyZetSw30Q8F5NDXSnsoT8J/zDLZCQ 59iL0NqDIom4nL7NrXYDGK44BMj/kUgAArWr6tbz6VrvCU7Wi8QcIJ+P0tpGmhOJ9q3A T8+GGQUPXMGneCUlqPosnzUrBm4Nqh5o7U6MNFNjx1ajC/+9c5rodV/HA+EAM7duDGMh uZLpQu8pJzzXipXeNMrJoLFytCW/GuxGjluGqwq+LtmT+sxXoxmxPmk4+XfkC6QkJoeo yoQQ==
MIME-Version: 1.0
X-Received: by 10.180.183.133 with SMTP id em5mr4371763wic.26.1366234345156; Wed, 17 Apr 2013 14:32:25 -0700 (PDT)
Received: by 10.194.28.195 with HTTP; Wed, 17 Apr 2013 14:32:25 -0700 (PDT)
In-Reply-To: <90099830fdb44516902b45476a184b92@BN1PR03MB072.namprd03.prod.outlook.com>
References: <CAKRe7JEiryo+Z4m2OMLibY2c4Eb5nZjfEMzoaADKNvshohh7eQ@mail.gmail.com> <20130414213939.GA6299@LK-Perkele-VII> <466ca70e40a648d0a691f550d1bf2e9a@BN1PR03MB072.namprd03.prod.outlook.com> <B170DCAB-AA5F-4850-9FAB-C04BB2414C18@mnot.net> <90099830fdb44516902b45476a184b92@BN1PR03MB072.namprd03.prod.outlook.com>
Date: Wed, 17 Apr 2013 14:32:25 -0700
Message-ID: <CABkgnnXz1EeGrns+kZo776eX5Wx3PHMJF-O52a3ODdTpsZYotg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
Cc: Mark Nottingham <mnot@mnot.net>, Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, Ilya Grigorik <ilya@igvita.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=209.85.212.174; envelope-from=martin.thomson@gmail.com; helo=mail-wi0-f174.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1USZyF-000485-9v f7b6980e6014c988f04bfa10aa370bdf
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP 2.0 "Upgrade" flow
Archived-At: <http://www.w3.org/mid/CABkgnnXz1EeGrns+kZo776eX5Wx3PHMJF-O52a3ODdTpsZYotg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17300
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've made Gabriel's suggested edits and cleaned up the first part of
the session header stuff.  It does help.

https://github.com/http2/http2-spec/commit/d6eefeafc362cd22a639bd608f8601b04820dc7b

Marks comment regarding the fictitious nature of the session header is
fair, but I find it an convenient abstraction from an editorial
perspective.  Again, YMMV.


On 17 April 2013 10:02, Gabriel Montenegro
<Gabriel.Montenegro@microsoft.com> wrote:
>> Personally, I'm not thrilled with how the server session header is conflated
>> with a SETTINGS frame... if we're going to require that the server send a
>> SETTINGS frame first (which is fine), let's just come out and say that, rather
>> than making it a side effect of requiring a (largely fictional) server session
>> header.
>
> The spec already says that in section 3.8.4 that a SETTINGS frame MUST be the first frame sent by either party in a new session.
>
> So that part is fine. If we wish to say that a server has no session header, that would be fine.
>
> As for " As proposed by Gabriel, SETTINGS (or equivalent) would/could be carried in the headers in the UPGRADE request."
>
> For the record, I did not say that in the Upgrade scenario the client session header is sent in HTTP/1.1 along with the Upgrade request. My understanding is that the Upgrade request goes without the client session header. As we have discussed in Orlando, we could add some HTTP/1.1 headers to address the known state by conveying *some* of the settings (only those absolutely necessary to achieve known initial state). But that's a separate proposal/discussion from this thread.
>
> At any rate, the server sends back the 101, and begins its HTTP/2.0 traffic by  sending its SETTINGS frame and its response frames, and the client upon receiving the 101, and only then, begins sending HTTP/2.0 traffic starting with its client session header (which includes the magic sequence and the client SETTINGS frame).
>
>