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

William Chan (陈智昌) <willchan@chromium.org> Tue, 23 April 2013 17:18 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 9703C21F96DF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Apr 2013 10:18:15 -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 22ABk1bT59GH for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Apr 2013 10:18:14 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCA621F96D2 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 23 Apr 2013 10:18:13 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UUgpy-0006gE-EP for ietf-http-wg-dist@listhub.w3.org; Tue, 23 Apr 2013 17:17:02 +0000
Resent-Date: Tue, 23 Apr 2013 17:17:02 +0000
Resent-Message-Id: <E1UUgpy-0006gE-EP@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 1UUgpp-0006fR-DA for ietf-http-wg@listhub.w3.org; Tue, 23 Apr 2013 17:16:53 +0000
Received: from mail-qc0-f180.google.com ([209.85.216.180]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1UUgpn-00077A-Oq for ietf-http-wg@w3.org; Tue, 23 Apr 2013 17:16:53 +0000
Received: by mail-qc0-f180.google.com with SMTP id b40so447034qcq.11 for <ietf-http-wg@w3.org>; Tue, 23 Apr 2013 10:16:26 -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=Zlk9Xxx+/6D7mj5EYO8byAX31ZtWPhQ3o+LZDd5T/9Y=; b=jhjWH4IiAHpFGJ7be5cw+J5XPltrYuuGIndlp8xSYegwI912n5ZbxwXdjEyNa/vV8o ftDZGfV34+5zdBs2TOdr7iF76f8Ne9or488QXEezNdHGrmWnpVekAjXcyqCpv2CMTHp8 mkVh05oXTJ49PpZgWQBaZjIvZAraGHTwg5YsDa96gZmga99Vs+ScWoXKcaYUbqzU+xhA TKoZ5T3w5aOLce2OVRRXd2mZZ5kOXtp0StISB6voXNLZguQxmG/cf21jXfmyY+nbC0hE bDt0e5PW1rqxESXe5frfa7U721Lj0+Z6SnbSZgVOr5UNCOxv6FUqtZysINOpz/WpUxXg YQLA==
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=Zlk9Xxx+/6D7mj5EYO8byAX31ZtWPhQ3o+LZDd5T/9Y=; b=ZeTDDMpD4jZYg7BalKYipW4lR76Yu6+n4mOr7MNPxubNBFVXmY7Cw4ysEHbyrBcOeF nW3+oDCPkW9pQYCTVAffnsoas/EubmPkuUPUnEAkRvjbTrt9k0zCeTy4sV6S74VI8xp9 f0kUr6jRcgUtfJJZlroHHjq1BhhcH+/YMgDB8=
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=Zlk9Xxx+/6D7mj5EYO8byAX31ZtWPhQ3o+LZDd5T/9Y=; b=dB0A2xf0RjgNXiGLoHDVhzHVpDUXTbHql+8uc87TU8JJu1rgXRny7s8FyCy/zcKKjN e0IYNwZm/6Zm09DIATySSWubS9xGZDNgmmxOtBr6SVS/DD0/02m9hTwUF1Zwb/47RR4G r4IdKQvvpPCGwzZ/TG1tc2z7GDwYWT/DGw5KGuFQK7GFwBRSenU/X8WVd1xRRF3sYehi CPoto+vQ9bZw8a6EZ33k7/TSiBThZzWAue+ai9ccYWKUmAUGDYj4io2HfKI4tB3+OfOd mKX9NpmycIJNRRmgLlJonya9mRrpc4ZtjKtT4qhTze3g8IenUhq09dCPp+4tReiie5O+ rtBg==
MIME-Version: 1.0
X-Received: by 10.224.210.10 with SMTP id gi10mr1340488qab.36.1366737386009; Tue, 23 Apr 2013 10:16:26 -0700 (PDT)
Sender: willchan@google.com
Received: by 10.229.180.4 with HTTP; Tue, 23 Apr 2013 10:16:25 -0700 (PDT)
In-Reply-To: <CAP+FsNe9UNY2Fj+fUA9M8DppmMr0NQ5VYsVCdVi0dddqT4VwBg@mail.gmail.com>
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>
Date: Tue, 23 Apr 2013 10:16:25 -0700
X-Google-Sender-Auth: Hbg6hudsPvM7r07-jv1mKS4_scA
Message-ID: <CAA4WUYgTTF+Tzo6qsOox6VOY6DzbPr4bigxoJiAqA01ScEgJkA@mail.gmail.com>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
To: Roberto Peon <grmocg@gmail.com>
Cc: Mark Nottingham <mnot@mnot.net>, Willy Tarreau <w@1wt.eu>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=20cf300faeed65175c04db0a5892
X-Gm-Message-State: ALoCoQlCOD69ZRc+8na4L32R1jI7jA7P3DIwUdSRdGryUgTdvwophNimc5b3taKtE0bJg6cYIJRqKfar7VNB4G+TMNoE6vvjb7pLYI5F+24V4xK6XKKWjNWUx20JkWjsO03y//U5UpaduEOGse73LEQDWWH1kEEIStv8YztIu4O9K1jHr4DD74q2zsCf1osqOUmXjcL0z4Xo
Received-SPF: pass client-ip=209.85.216.180; envelope-from=willchan@google.com; helo=mail-qc0-f180.google.com
X-W3C-Hub-Spam-Status: No, score=-4.5
X-W3C-Hub-Spam-Report: AWL=-1.760, 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 1UUgpn-00077A-Oq 7e0b50471d12b4ed2dbabcf37088087c
X-Original-To: ietf-http-wg@w3.org
Subject: Re: p1: Upgrade ordering (possible HTTP/2 impact)
Archived-At: <http://www.w3.org/mid/CAA4WUYgTTF+Tzo6qsOox6VOY6DzbPr4bigxoJiAqA01ScEgJkA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17507
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 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/
>>
>>
>>
>>
>