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

Mark Nottingham <mnot@mnot.net> Tue, 23 April 2013 07:39 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 92E6E21F964C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Apr 2013 00:39:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.512
X-Spam-Level:
X-Spam-Status: No, score=-10.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 BH-eJBEg0ajy for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Apr 2013 00:39:46 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id B8CF921F8D90 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 23 Apr 2013 00:39:46 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UUXp2-0006sD-Fo for ietf-http-wg-dist@listhub.w3.org; Tue, 23 Apr 2013 07:39:28 +0000
Resent-Date: Tue, 23 Apr 2013 07:39:28 +0000
Resent-Message-Id: <E1UUXp2-0006sD-Fo@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UUXoy-0006rT-JJ for ietf-http-wg@listhub.w3.org; Tue, 23 Apr 2013 07:39:24 +0000
Received: from mxout-08.mxes.net ([216.86.168.183]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UUXox-0001Jy-Lr for ietf-http-wg@w3.org; Tue, 23 Apr 2013 07:39:24 +0000
Received: from [192.168.1.80] (unknown [118.209.190.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2007F50A84 for <ietf-http-wg@w3.org>; Tue, 23 Apr 2013 03:39:01 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <20130420071736.GK26517@1wt.eu>
Date: Tue, 23 Apr 2013 17:38:59 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <BA1DBB8B-2E4D-49F5-AE98-F089A568BD4E@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>
To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
X-Mailer: Apple Mail (2.1503)
Received-SPF: pass client-ip=216.86.168.183; envelope-from=mnot@mnot.net; helo=mxout-08.mxes.net
X-W3C-Hub-Spam-Status: No, score=-4.3
X-W3C-Hub-Spam-Report: AWL=-2.406, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UUXox-0001Jy-Lr 270fb89a50e36d8ea7692613f39d0b77
X-Original-To: ietf-http-wg@w3.org
Subject: Re: p1: Upgrade ordering (possible HTTP/2 impact)
Archived-At: <http://www.w3.org/mid/BA1DBB8B-2E4D-49F5-AE98-F089A568BD4E@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17492
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>

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.
"""


On 20/04/2013, at 5:17 PM, Willy Tarreau <w@1wt.eu>; wrote:

> On Sat, Apr 20, 2013 at 05:13:09PM +1000, Mark Nottingham wrote:
>> 
>> On 20/04/2013, at 5:10 PM, Willy Tarreau <w@1wt.eu>; wrote:
>> 
>>> On Sat, Apr 20, 2013 at 02:07:57PM +1000, Mark Nottingham wrote:
>>>> p1 section 6.7 defines the Upgrade header, but no where does it say anything
>>>> about relative preference.
>>>> 
>>>> Should we define (or at least allow) for the ordering to be semantically
>>>> significant? It seems to me that if we end up using this, and there are a few
>>>> different variants of HTTP/2 (e.g., "normal" vs "mobile"), it'd be nice to
>>>> rely on ordering here.
>>> 
>>> Indeed it could be quite useful! RFC2817 does not suggest anything concerning
>>> multiple values in the Upgrade header field for the request message, it only
>>> suggests that the response describes the protocol stack (eg: TLS/1.0, HTTP/1.1).
>>> 
>>> So I'm wondering if it would not be a abit awkward to have a different
>>> definition of this header field depending on the direction. Some more thinking
>>> is needed on this I suppose.
>> 
>> 
>> We're already there; in the current form, it describes the protocols the
>> client can upgrade to in requests, whereas in 101 responses it describes the
>> (single) protocol the server *is* upgrading to.
> 
> OK so your suggestion makes pretty much sense then, we could probably state
> that servers should pick the first one they support and that clients supporting
> multiple protocols order them by preference ?
> 
> Willy
> 
> 

--
Mark Nottingham   http://www.mnot.net/