Re: HTTP 2.0 "Upgrade" flow

Martin Thomson <martin.thomson@gmail.com> Wed, 17 April 2013 22:12 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 673361F0D1A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Apr 2013 15:12:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.424
X-Spam-Level:
X-Spam-Status: No, score=-10.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 0AqyLhoZe4XV for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Apr 2013 15:12:20 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3801F0D1E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 17 Apr 2013 15:12:20 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1USaZm-00088B-6S for ietf-http-wg-dist@listhub.w3.org; Wed, 17 Apr 2013 22:11:38 +0000
Resent-Date: Wed, 17 Apr 2013 22:11:38 +0000
Resent-Message-Id: <E1USaZm-00088B-6S@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 1USaZi-00086j-So for ietf-http-wg@listhub.w3.org; Wed, 17 Apr 2013 22:11:34 +0000
Received: from mail-wi0-f180.google.com ([209.85.212.180]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1USaZg-0005TZ-VK for ietf-http-wg@w3.org; Wed, 17 Apr 2013 22:11:34 +0000
Received: by mail-wi0-f180.google.com with SMTP id h11so970501wiv.7 for <ietf-http-wg@w3.org>; Wed, 17 Apr 2013 15:11:06 -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=qSN0knCzNpNCeNhkuu5KHnFgJzGznttrP/BV7mmY8X0=; b=C/ttTqKlNG85j6cll1sdiLO8Wu9S67NdPVe3pdf22I1WN4UBUcQn7F9/q1yAPXY2// Cq9UBb7TTVDUwTPF2/idej7gI8pVv3WJohHbupblwa/mJSQbMeXGJJFLxRu9kiHs3XNl 96RvYk6rtCrfriPQ4J9yx08SDNacz5m1gbyEWmBw3dXEKwvXIy5trdJ26xccVLyWimef Z3yfSbHXwhdHMcxwJzyMz02Mh0SisyZormkP6D9NwSdM1hPwfx1QxOaxhL/4m7eNR5mI EbZcEOtRI5d/2wOksJdmPUqGmqczBZaJjAQ0VVDTr/RQwTYLMmF8e6ffe0XUQy55ErQa INgA==
MIME-Version: 1.0
X-Received: by 10.194.103.72 with SMTP id fu8mr14328236wjb.42.1366236666871; Wed, 17 Apr 2013 15:11:06 -0700 (PDT)
Received: by 10.194.28.195 with HTTP; Wed, 17 Apr 2013 15:11:06 -0700 (PDT)
In-Reply-To: <em69423ffd-502e-4039-b54f-d6239b733acc@bombed>
References: <CABkgnnV-488_Y_ytuFVkG9NuT0PnBeYS38z1BTQ_wVLT-e-12w@mail.gmail.com> <em69423ffd-502e-4039-b54f-d6239b733acc@bombed>
Date: Wed, 17 Apr 2013 15:11:06 -0700
Message-ID: <CABkgnnVP_4BCwiUd9ZpVzr8WLJjxqOkd82WK8yncseO8fRV_zA@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=209.85.212.180; envelope-from=martin.thomson@gmail.com; helo=mail-wi0-f180.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.655, 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 1USaZg-0005TZ-VK 354b987930f6c920ffea9351c0b42ded
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP 2.0 "Upgrade" flow
Archived-At: <http://www.w3.org/mid/CABkgnnVP_4BCwiUd9ZpVzr8WLJjxqOkd82WK8yncseO8fRV_zA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17310
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 think that you either send the session header immediately after the
first request (the Upgrade) and risk having it swalled, or you send it
immediately before the next (HTTP/2.0) request.  In either case, you
don't incur an RTT delay.

If you thought that the server would wait for the client session
header before sending its SETTINGS, then I don't think that was every
the intention (the recent edits from Gabriel fix that problem, I
hope).  That would add an RTT and we don't want that.

On 17 April 2013 15:07, Adrien W. de Croy <adrien@qbik.com> wrote:
>
> my main concern is what does a forward proxy do.
>
> the client may choose to maintain a database of known http2 capable servers.
> This may be too much of a burden for the proxy.
>
> Discovery at the proxy could be a bit of a burden as well.
>
> A proxy offering 2.0 support to 2.0 clients but still having to talk to the
> great unwashed internet has quite a dilemma.  The safe/lazy/whatever option
> for the proxy may be to always use the Upgrade option.  Adding a RTT in this
> case will be seen by clients/customers as a performance degradation in many
> cases.
>
> Or maybe I've not thought this through properly.
>
>
> Adrien
>
>
> ------ Original Message ------
> From: "Martin Thomson" <martin.thomson@gmail.com>
> To: "Adrien W. de Croy" <adrien@qbik.com>
> Cc: "Gabriel Montenegro" <Gabriel.Montenegro@microsoft.com>om>; "Mark
> Nottingham" <mnot@mnot.net>et>; "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 10:00:47 a.m.
> Subject: Re: HTTP 2.0 "Upgrade" flow
>>
>> So you intend to make client SETTINGS available to the server prior to
>> the server commencing transmission. This is the essence of what
>> Gabriel intends with his known state proposal. He is concerned by the
>> asymmetry of the exchange when Upgrade is involved (as opposed to the
>> TLS session startup). You should talk to Gabriel.
>>
>> On 17 April 2013 14:56, Adrien W. de Croy <adrien@qbik.com> wrote:
>>>
>>>
>>>  I think it would need to go in as a header. Maybe even as an attribute
>>> to
>>>  the Upgrade? Not sure if that supports such things. E.g.
>>>
>>>  GET /bob.txt HTTP/1.1
>>>  Host: somewhere.co.nz
>>>  Upgrade: HTTP/2.0 ; session=[......]
>>>
>>>  so that the server can respond with the resource in any case.
>>>
>>>  Adding a RTT to all HTTP 2.0 connections I thought had been decided was
>>> a
>>>  non-starter. Or compared to TLS setup phase + NPN maybe it's no worse.
>>>
>>>
>>>  Adrien
>>>
>>>
>>>  ------ Original Message ------
>>>  From: "Martin Thomson" <martin.thomson@gmail.com>
>>>  To: "Adrien W. de Croy" <adrien@qbik.com>
>>>  Cc: "Gabriel Montenegro" <Gabriel.Montenegro@microsoft.com>om>; "Mark
>>>  Nottingham" <mnot@mnot.net>et>; "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 9:51:47 a.m.
>>>  Subject: Re: HTTP 2.0 "Upgrade" flow
>>>>
>>>>
>>>>  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).
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>