IETF Logo Mail Archive

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

Willy Tarreau <w@1wt.eu> Tue, 30 April 2013 05:45 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 D550921F9C21 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 29 Apr 2013 22:45:30 -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=[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 JPi2h174HUuD for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 29 Apr 2013 22:45:23 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCBF21F9C07 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 29 Apr 2013 22:45:22 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UX3MD-0006XM-EK for ietf-http-wg-dist@listhub.w3.org; Tue, 30 Apr 2013 05:44:06 +0000
Resent-Date: Tue, 30 Apr 2013 05:44:05 +0000
Resent-Message-Id: <E1UX3MD-0006XM-EK@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <w@1wt.eu>) id 1UX3M3-0006Wb-PK for ietf-http-wg@listhub.w3.org; Tue, 30 Apr 2013 05:43:55 +0000
Received: from 1wt.eu ([62.212.114.60]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <w@1wt.eu>) id 1UX3M2-0004h5-EG for ietf-http-wg@w3.org; Tue, 30 Apr 2013 05:43:55 +0000
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id r3U5hUIT021531; Tue, 30 Apr 2013 07:43:30 +0200
Date: Tue, 30 Apr 2013 07:43:30 +0200
From: Willy Tarreau <w@1wt.eu>
To: Mark Nottingham <mnot@mnot.net>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-ID: <20130430054330.GB21517@1wt.eu>
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> <F786D0A4-F4BD-4A85-8078-F6BBCABA32AC@mnot.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <F786D0A4-F4BD-4A85-8078-F6BBCABA32AC@mnot.net>
User-Agent: Mutt/1.4.2.3i
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-4.3
X-W3C-Hub-Spam-Report: AWL=-1.839, RP_MATCHES_RCVD=-2.442, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UX3M2-0004h5-EG c21ff7c1f0afcdcdb3935de0422a78f2
X-Original-To: ietf-http-wg@w3.org
Subject: Re: p1: Upgrade ordering (possible HTTP/2 impact)
Archived-At: <http://www.w3.org/mid/20130430054330.GB21517@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17713
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>

On Tue, Apr 30, 2013 at 01:20:14PM +1000, Mark Nottingham wrote:
> I'm going to mark this resoution for incorporation into -23.

OK, then fixing a typo in my own text below :

  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
+ it might be willing to upgrade to one of the specified protocols for
  a future request, in order of relative preference.

Willy

v2.23.0 | Report a Bug | By Email