Re: HTTP 2.0 "Upgrade" flow

Martin Thomson <> Wed, 17 April 2013 21:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A17A521E80EF for <>; Wed, 17 Apr 2013 14:33:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gVdKESro9yqS for <>; Wed, 17 Apr 2013 14:33:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8FCC621E80EC for <>; Wed, 17 Apr 2013 14:33:47 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1USZyI-0005D9-NA for; Wed, 17 Apr 2013 21:32:54 +0000
Resent-Date: Wed, 17 Apr 2013 21:32:54 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1USZyF-0005BR-VR for; Wed, 17 Apr 2013 21:32:51 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1USZyF-000485-9v for; Wed, 17 Apr 2013 21:32:51 +0000
Received: by with SMTP id m6so3105641wiv.7 for <>; Wed, 17 Apr 2013 14:32:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id em5mr4371763wic.26.1366234345156; Wed, 17 Apr 2013 14:32:25 -0700 (PDT)
Received: by with HTTP; Wed, 17 Apr 2013 14:32:25 -0700 (PDT)
In-Reply-To: <>
References: <> <20130414213939.GA6299@LK-Perkele-VII> <> <> <>
Date: Wed, 17 Apr 2013 14:32:25 -0700
Message-ID: <>
From: Martin Thomson <>
To: Gabriel Montenegro <>
Cc: Mark Nottingham <>, Ilari Liusvaara <>, Ilya Grigorik <>, " Group" <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=;;
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: 1USZyF-000485-9v f7b6980e6014c988f04bfa10aa370bdf
Subject: Re: HTTP 2.0 "Upgrade" flow
Archived-At: <>
X-Mailing-List: <> archive/latest/17300
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

I've made Gabriel's suggested edits and cleaned up the first part of
the session header stuff.  It does help.

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
<> 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).