Re: HTTP 2.0 "Upgrade" flow
"Adrien W. de Croy" <adrien@qbik.com> Wed, 17 April 2013 22:08 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 40C7F1F0D16 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Apr 2013 15:08:20 -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=[AWL=0.000, 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 7+rDT9-5Lug2 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Apr 2013 15:08:19 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 61A8C1F0D12 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 17 Apr 2013 15:08:19 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1USaWG-00060M-Ru for ietf-http-wg-dist@listhub.w3.org; Wed, 17 Apr 2013 22:08:00 +0000
Resent-Date: Wed, 17 Apr 2013 22:08:00 +0000
Resent-Message-Id: <E1USaWG-00060M-Ru@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <adrien@qbik.com>) id 1USaWE-0005zh-4V for ietf-http-wg@listhub.w3.org; Wed, 17 Apr 2013 22:07:58 +0000
Received: from smtp.qbik.com ([210.55.214.35]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <adrien@qbik.com>) id 1USaWD-0002gh-0c for ietf-http-wg@w3.org; Wed, 17 Apr 2013 22:07:58 +0000
Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v8.0.0 (Build 3531)) with SMTP id <0019655109@smtp.qbik.com>; Thu, 18 Apr 2013 10:07:34 +1200
From: "Adrien W. de Croy" <adrien@qbik.com>
To: Martin Thomson <martin.thomson@gmail.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>
Date: Wed, 17 Apr 2013 22:07:34 +0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; format="flowed"; charset="utf-8"
In-Reply-To: <CABkgnnV-488_Y_ytuFVkG9NuT0PnBeYS38z1BTQ_wVLT-e-12w@mail.gmail.com>
Message-Id: <em69423ffd-502e-4039-b54f-d6239b733acc@bombed>
Mime-Version: 1.0
Reply-To: "Adrien W. de Croy" <adrien@qbik.com>
User-Agent: eM_Client/5.0.17595.0
Received-SPF: pass client-ip=210.55.214.35; envelope-from=adrien@qbik.com; helo=smtp.qbik.com
X-W3C-Hub-Spam-Status: No, score=-3.6
X-W3C-Hub-Spam-Report: AWL=-3.067, RP_MATCHES_RCVD=-0.556, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1USaWD-0002gh-0c a566d7c452a2f840599d07f7c49b62ce
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP 2.0 "Upgrade" flow
Archived-At: <http://www.w3.org/mid/em69423ffd-502e-4039-b54f-d6239b733acc@bombed>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17309
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>
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>; "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> 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>; "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> >> 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>; "Ilya >>>>Grigorik" >>>> <ilya@igvita.com>; "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). >>>>> >>>>> >>>> >>>> >>
- HTTP 2.0 "Upgrade" flow Ilya Grigorik
- Re: HTTP 2.0 "Upgrade" flow Ilari Liusvaara
- Re: HTTP 2.0 "Upgrade" flow Ilya Grigorik
- RE: HTTP 2.0 "Upgrade" flow Gabriel Montenegro
- Re: HTTP 2.0 "Upgrade" flow Roberto Peon
- Re: HTTP 2.0 "Upgrade" flow Ilya Grigorik
- Re: HTTP 2.0 "Upgrade" flow Roberto Peon
- Re: HTTP 2.0 "Upgrade" flow Adrien W. de Croy
- Re: HTTP 2.0 "Upgrade" flow Roberto Peon
- Re: HTTP 2.0 "Upgrade" flow Amos Jeffries
- Re: HTTP 2.0 "Upgrade" flow Roberto Peon
- Re: HTTP 2.0 "Upgrade" flow Willy Tarreau
- Re: HTTP 2.0 "Upgrade" flow Roberto Peon
- Re: HTTP 2.0 "Upgrade" flow Mark Nottingham
- RE: HTTP 2.0 "Upgrade" flow Gabriel Montenegro
- Re: HTTP 2.0 "Upgrade" flow Martin Thomson
- Re: HTTP 2.0 "Upgrade" flow Martin Thomson
- Re: HTTP 2.0 "Upgrade" flow Adrien W. de Croy
- Re: HTTP 2.0 "Upgrade" flow Martin Thomson
- Re: HTTP 2.0 "Upgrade" flow Adrien W. de Croy
- Re: HTTP 2.0 "Upgrade" flow Martin Thomson
- Re: HTTP 2.0 "Upgrade" flow Adrien W. de Croy
- Re: HTTP 2.0 "Upgrade" flow Adrien W. de Croy
- RE: HTTP 2.0 "Upgrade" flow Gabriel Montenegro
- Re: HTTP 2.0 "Upgrade" flow Adrien W. de Croy