Re: p1: Upgrade ordering (possible HTTP/2 impact)

William Chan (陈智昌) <willchan@chromium.org> Wed, 24 April 2013 00:32 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 AFE6F21F9660 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Apr 2013 17:32:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.676
X-Spam-Level:
X-Spam-Status: No, score=-9.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 orsbzQbj7ooz for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Apr 2013 17:32:18 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0F52721F9659 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 23 Apr 2013 17:32:18 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UUncC-0008E0-8r for ietf-http-wg-dist@listhub.w3.org; Wed, 24 Apr 2013 00:31:16 +0000
Resent-Date: Wed, 24 Apr 2013 00:31:16 +0000
Resent-Message-Id: <E1UUncC-0008E0-8r@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <willchan@google.com>) id 1UUnc4-0008DB-Ij for ietf-http-wg@listhub.w3.org; Wed, 24 Apr 2013 00:31:08 +0000
Received: from mail-qe0-f50.google.com ([209.85.128.50]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1UUnc3-0006dW-Bw for ietf-http-wg@w3.org; Wed, 24 Apr 2013 00:31:08 +0000
Received: by mail-qe0-f50.google.com with SMTP id a11so856168qen.37 for <ietf-http-wg@w3.org>; Tue, 23 Apr 2013 17:30:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=WoAEyAVw5iNyJNBEx2AFdD8NjAMwrV+aJFAWMsXgqXM=; b=gw+P5GEHUd6I+GaRP93i2dDeJZgoNTWPAIzEDP1DGlz+wLJ4X7WwrnFsnwWCyuH8p6 kwjQ/UUSyn0WvOxRgH66O0F/vOIfHJqwISvoF3h0Cn0NA87PiQBLNvqT8A1td0gwelvj oFePPSNjwAn0oc3tZZarzmIjm4aww2/H2GmowAaC5PvZ4StgRQcjdfZ/JXtGOzkQB8R7 fFqO/kK+szpm3to3pZlIQB1yflaOk04x0joNYetrAbvl3cQWdBb/meolV3BE9SocfpsO ut12La2ABWqnwQzSMg7qlLVtGDR4tnQE4xiIZn5vCTqD5wEIcCMbTPROqvXqzUNyQv/A HI4Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=WoAEyAVw5iNyJNBEx2AFdD8NjAMwrV+aJFAWMsXgqXM=; b=BBm4s1X4t66UTiRRoabWxLC9szBHMA/Z1892/z3Ns9rGD2ReE2ZZn/RwCJ4RDAr9G+ b8TGbGT4eRjU8Du0LWtzS0yTZANO5oU6VDwi4iEQOiVjxYEK1n5oyWdzQ/T7qSLJSjIP sZMNdNqVHgSSrOdPvENBPLbGEjWgOfj2zdtM8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=WoAEyAVw5iNyJNBEx2AFdD8NjAMwrV+aJFAWMsXgqXM=; b=oURheUr/x1I1j7r9biYBHGYAdiQyoD40SznW71Sy274SZhvM6bvW9Pol6PidFj3+of SAa/L8F9syo6/7VrFtse+QkPwg2+QyvjYGRS1s6RJPq03yWkLdJolCfiY8gnV8IWO1fw zsX2qX6KD8oUVvGtEE2eM8n1OAU63UasNjQT3fuXnSiv90roSo02E8XZkx2UWgE/ZdTe TmUHNFGs+b8S57Jv2AxzBm7kfsKw2pULE+RtPEnt3f/AWjUwBT2ybkmJWsYzwo7PQH7n UyogMMKcPkEBU5jFHb8GIDrEOun38EWbx4jghM6x+4NSybina7mqZRP/JX+Qxd5buVQn tozg==
MIME-Version: 1.0
X-Received: by 10.224.210.10 with SMTP id gi10mr2531285qab.36.1366763441675; Tue, 23 Apr 2013 17:30:41 -0700 (PDT)
Sender: willchan@google.com
Received: by 10.229.180.4 with HTTP; Tue, 23 Apr 2013 17:30:41 -0700 (PDT)
In-Reply-To: <8CA9C65B-6B43-4E38-B422-4F5FF087D784@mnot.net>
References: <B49447FF-CB94-43ED-9CA2-0698C64BB554@mnot.net> <20130420071042.GI26517@1wt.eu> <77849350-125C-4F36-8D78-0FF86DA0044E@mnot.net> <20130420071736.GK26517@1wt.eu> <BA1DBB8B-2E4D-49F5-AE98-F089A568BD4E@mnot.net> <20130423081209.GH8496@1wt.eu> <7B3A3DD8-BB24-4E09-831B-D27416B31622@mnot.net> <CAP+FsNe_xGvZSveE4hW0YmSTPvcbVytqtN5NX1wu2TmMH9w5QA@mail.gmail.com> <00F2FE82-F9A7-40AD-B829-6D82C16A75A4@mnot.net> <CAP+FsNe9UNY2Fj+fUA9M8DppmMr0NQ5VYsVCdVi0dddqT4VwBg@mail.gmail.com> <CAA4WUYgTTF+Tzo6qsOox6VOY6DzbPr4bigxoJiAqA01ScEgJkA@mail.gmail.com> <8CA9C65B-6B43-4E38-B422-4F5FF087D784@mnot.net>
Date: Tue, 23 Apr 2013 17:30:41 -0700
X-Google-Sender-Auth: fIg_PKSYUHburGN5KhhUZN8382M
Message-ID: <CAA4WUYi5xhyX+-kAxeUa5rxUevO2XMZtqOwV=pna5ByS4zyOjw@mail.gmail.com>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
To: Mark Nottingham <mnot@mnot.net>
Cc: Roberto Peon <grmocg@gmail.com>, Willy Tarreau <w@1wt.eu>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=20cf300faeed6ef13104db1069b9
X-Gm-Message-State: ALoCoQmrHRCyWguRcRQ74ArKUXGLNr/dyWlJ1YmxLAVqUgiui4OR/c5JxuHdKOgR3jHnzecQ8/+Dbbg2ggjnyGTFdgKdfxCRjueoWeO/+KfcHMwFVmf6WzGsvNCqCjrQCzDfvW+XlCVQ59ipFBXAt/pLPh2VPVRR8cwZGU1h/HmO81eFJKiIIkGq0Zsa3/OVquwxCWJc/m+y
Received-SPF: pass client-ip=209.85.128.50; envelope-from=willchan@google.com; helo=mail-qe0-f50.google.com
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.741, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UUnc3-0006dW-Bw d9e8e3e09cfe96bbbb14acef0cd2b8c3
X-Original-To: ietf-http-wg@w3.org
Subject: Re: p1: Upgrade ordering (possible HTTP/2 impact)
Archived-At: <http://www.w3.org/mid/CAA4WUYi5xhyX+-kAxeUa5rxUevO2XMZtqOwV=pna5ByS4zyOjw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17514
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>

That's an important semantic difference, thanks for highlighting it. If
that's the case, then returning a token like 443:tls-alpn-http/2 makes no
sense, since that would be on a separate connection, right? I think if
we're solely speaking about this connection, then a naked HTTP/2 string is
sufficient (and if you wanted to do StartTLS, you could use a different
string).


On Tue, Apr 23, 2013 at 3:15 PM, Mark Nottingham <mnot@mnot.net>; wrote:

> Keep in mind that Upgrade on a non-101 response is about advertising the
> possibility to upgrade *this* connection, whereas Alternate-Protocol is
> about advertising the potential to upgrade by switching connections.
>
>
> On 24/04/2013, at 3:16 AM, William Chan (陈智昌) <willchan@chromium.org>;
> wrote:
>
> > I think adding the relative preference semantic is good.
> >
> > I have to confess I was not aware of using Upgrade as a response header
> outside of a 101 or 426 response. This indeed sounds very similar to
> Alternate-Protocol. Is anyone actually using this in practice?
> >
> >
> > On Tue, Apr 23, 2013 at 2:46 AM, Roberto Peon <grmocg@gmail.com>; wrote:
> > Excellent. Almost at the point of not needing alternate-protocol. :)
> >
> > The last difference here is that alternate-protocol allows the client to
> cache this data, so that it may negotiate the new protocol (on some future
> connection) potentially without being forced to do an upgrade.
> >
> > Today, this mainly is interesting for resources with an http scheme
> being served over an encrypted channel where the upgrade isn't necessary.
> With the value in the upgrade field cached, the browser can see an http
> scheme for that origin and immediately make an ALPN-negotiated connection
> >
> > -=R
> >
> >
> > On Tue, Apr 23, 2013 at 2:35 AM, Mark Nottingham <mnot@mnot.net>; wrote:
> > On 23/04/2013, at 7:24 PM, Roberto Peon <grmocg@gmail.com>; wrote:
> >
> > > A complication here is that it isn't sufficient to state the protocol
> as HTTP/2
> > > As an example assuming we may wish to use the version that negotiates
> using ALPN over TLS/:443, we'd be unhappy unless we become more specific
> about what the various version strings for (at least) HTTP/2 will mean in
> this field.
> >
> > I think that's the plan...
> >
> > > In alternate-protocol, this was dealt with by having different version
> strings for the possibly different negotiation mechanisms (though nothing
> but NPN was really used), e.g.
> > > npn-http/2 vs http/2 or, more completely, 443:npn-http/2 or 80:http/2
> > >
> > > -=R
> > >
> > >
> > > On Tue, Apr 23, 2013 at 1:14 AM, Mark Nottingham <mnot@mnot.net>;
> wrote:
> > > WFM
> > >
> > > On 23/04/2013, at 6:12 PM, Willy Tarreau <w@1wt.eu>; wrote:
> > >
> > > > Hi Mark,
> > > >
> > > > On Tue, Apr 23, 2013 at 05:38:59PM +1000, Mark Nottingham wrote:
> > > >> Proposal - add to p1 6.7:
> > > >>
> > > >> """
> > > >> When occurring in a request, Upgrade's value indicate the
> protocol(s) the
> > > >> client would like to upgrade to, in order of relative preference.
> When
> > > >> occurring in a 101 (Switching Protocols) response, there will
> usually only be
> > > >> one protocol indicated in Upgrade. When occurring in any other
> response,
> > > >> Upgrade indicates the protocol(s) the server is capable of
> upgrading to, in
> > > >> order of relative preference.
> > > >> """
> > > >
> > > > I'm OK in the principle, though I think this should be fused into
> existing
> > > > text, probably that way :
> > > >
> > > >   The "Upgrade" header field is intended to provide a simple
> mechanism
> > > >   for transitioning from HTTP/1.1 to some other protocol on the same
> > > >   connection.  A client MAY send a list of protocols in order of
> relative
> > > >   preference in the Upgrade header field of a request to invite the
> server
> > > >   to switch to one or more of those protocols before sending the
> final
> > > >   response.  A server MUST send an Upgrade header field in 101
> (Switching
> > > >   Protocols) responses to indicate which protocol(s) are being
> switched
> > > >   to, and MUST send it in 426 (Upgrade Required) responses to
> indicate
> > > >   acceptable protocols in order of relative preference.  A server MAY
> > > >   send an Upgrade header field in any other response to indicate that
> > > >   they might be willing to upgrade to one of the specified protocols
> for
> > > >   a future request, in order of relative preference.
> > > >
> > > > Willy
> > > >
> > >
> > > --
> > > Mark Nottingham   http://www.mnot.net/
> > >
> > >
> > >
> > >
> > >
> >
> > --
> > Mark Nottingham   http://www.mnot.net/
> >
> >
> >
> >
> >
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>