Re: HTTP 2.0 "Upgrade" flow

Martin Thomson <martin.thomson@gmail.com> Wed, 17 April 2013 21:52 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 21ABB21F8CEE for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Apr 2013 14:52:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.224
X-Spam-Level:
X-Spam-Status: No, score=-8.224 tagged_above=-999 required=5 tests=[AWL=2.375, 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 tRtuilP5He8h for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Apr 2013 14:52:28 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id D168E21F8C55 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 17 Apr 2013 14:52:27 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1USaH2-000706-MA for ietf-http-wg-dist@listhub.w3.org; Wed, 17 Apr 2013 21:52:16 +0000
Resent-Date: Wed, 17 Apr 2013 21:52:16 +0000
Resent-Message-Id: <E1USaH2-000706-MA@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 1USaH0-0006zH-1S for ietf-http-wg@listhub.w3.org; Wed, 17 Apr 2013 21:52:14 +0000
Received: from mail-wg0-f47.google.com ([74.125.82.47]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1USaGz-0004iz-CD for ietf-http-wg@w3.org; Wed, 17 Apr 2013 21:52:13 +0000
Received: by mail-wg0-f47.google.com with SMTP id j13so2083468wgh.26 for <ietf-http-wg@w3.org>; Wed, 17 Apr 2013 14:51:47 -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=gZvo0KbHqYV+Y6GQ2sHczRlnyZzkLVuMMpcRTOkFMRE=; b=ckHFc2roaZcxBzo2jPkUWYsN+z6q1E4IhxfRz0K187ZoCJFEdxYr8qlgW777l1oTPW GqvqaqaLbnJaCfF+3oUbniaWFR/DPinpFcC4IN33aOJ1lq8H7GQ6+YsIzfZAGh/MG5MR qIk5xKDPF6cgjtnq5Q88nw+FAM44sqKMjKQ7xRTe6HkGT6d8SskGPnCCF/IxJZ3ASfpV DfYBDud5Lh5zDfZzmi/imNv+/ulKFt1EB9lVZKTGxQ4cHwfA+HmqYszr9th4yNz3P7aN KLcWZkl63iVRc2OyyZV3kHhahjBkF76PYYMYV1Qry/tUFBUaeuHVp4zrhiDd1mrfBNBn QTvA==
MIME-Version: 1.0
X-Received: by 10.180.83.199 with SMTP id s7mr11721997wiy.19.1366235507283; Wed, 17 Apr 2013 14:51:47 -0700 (PDT)
Received: by 10.194.28.195 with HTTP; Wed, 17 Apr 2013 14:51:47 -0700 (PDT)
In-Reply-To: <emfb65ac6f-f6f7-48bc-abd8-0b9e9f7b8cda@bombed>
References: <90099830fdb44516902b45476a184b92@BN1PR03MB072.namprd03.prod.outlook.com> <emfb65ac6f-f6f7-48bc-abd8-0b9e9f7b8cda@bombed>
Date: Wed, 17 Apr 2013 14:51:47 -0700
Message-ID: <CABkgnnVq27RCHs=hCQTr97urQc54pHdMPKQ6+WXwHYxdA_tnkA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "Adrien W. de Croy" <adrien@qbik.com>
Cc: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, 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
Received-SPF: pass client-ip=74.125.82.47; envelope-from=martin.thomson@gmail.com; helo=mail-wg0-f47.google.com
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-2.593, 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 1USaGz-0004iz-CD 395f1dfc098537463d9bffae1e876795
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP 2.0 "Upgrade" flow
Archived-At: <http://www.w3.org/mid/CABkgnnVq27RCHs=hCQTr97urQc54pHdMPKQ6+WXwHYxdA_tnkA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17305
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>

It's possible that the client could pipeline the session header, but
that does stand a chance of being subsumed into the initial request.
I expect packet-based hacks.

On 17 April 2013 14:42, Adrien W. de Croy <adrien@qbik.com> wrote:
>
> My understanding was that we would not be sacrificing the first request due
> to a requirement to upgrade.
>
> In order for the server to send an actual response, if it needs the client
> session header, this should be sent in the initial request which includes
> the upgrade.
>
> Otherwise we just added a RTT
>
>
> Adrien
>
>
> ------ Original Message ------
> From: "Gabriel Montenegro" <Gabriel.Montenegro@microsoft.com>
> To: "Mark Nottingham" <mnot@mnot.net>
> Cc: "Ilari Liusvaara" <ilari.liusvaara@elisanet.fi>fi>; "Ilya Grigorik"
> <ilya@igvita.com>om>; "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
> Sent: 18/04/2013 5:02:01 a.m.
> Subject: RE: HTTP 2.0 "Upgrade" flow
>>>
>>>  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).
>>
>>
>
>