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

Roberto Peon <grmocg@gmail.com> Tue, 23 April 2013 09:47 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 73A5921F964D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Apr 2013 02:47:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.273
X-Spam-Level:
X-Spam-Status: No, score=-10.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 qTelaFO5UPQj for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Apr 2013 02:47:27 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 875F521F95E0 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 23 Apr 2013 02:47:27 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UUZoN-00040e-Mh for ietf-http-wg-dist@listhub.w3.org; Tue, 23 Apr 2013 09:46:55 +0000
Resent-Date: Tue, 23 Apr 2013 09:46:55 +0000
Resent-Message-Id: <E1UUZoN-00040e-Mh@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UUZoI-0003zc-W7 for ietf-http-wg@listhub.w3.org; Tue, 23 Apr 2013 09:46:51 +0000
Received: from mail-oa0-f42.google.com ([209.85.219.42]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UUZoH-0006hq-KY for ietf-http-wg@w3.org; Tue, 23 Apr 2013 09:46:50 +0000
Received: by mail-oa0-f42.google.com with SMTP id i10so375881oag.1 for <ietf-http-wg@w3.org>; Tue, 23 Apr 2013 02:46:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=vTJmYyX1/dR6pGB8ZmlHIoI7GfsW/Fn4ThqoAQIplsI=; b=x0lnEGfP9gPgdn7p8+5tVMj7eCdv/B6TEGwC53ihtK3euYbPZv7TnkOY6+ew0+iOds mf6VXG3FSTNt+gL3TtckuS8ATNP7mxlgCQPOTTGxIytsye+AvrDIlSPlxJpxsBRYpTsU R/8p9Zy+hGX1DlU9rnhSS+wVxSlrIsS0fuMCGzPZGRTOq7ObpJRdr8NmMKoYPkCHT+PQ 11GT3+6a9JcLJpoof2E/Leq2a6Fq4Vtf3rHUHpGH8My+/fnG6X5ebkZxv0cuwpq3TP5l hRGJYXoRRV8XlOAvE8jK4ue85mmCLE5QW3dIJVGUn7paDoKnsdCdhdWM9ABCSS78j67D Vgig==
MIME-Version: 1.0
X-Received: by 10.182.102.228 with SMTP id fr4mr741021obb.84.1366710383624; Tue, 23 Apr 2013 02:46:23 -0700 (PDT)
Received: by 10.76.12.103 with HTTP; Tue, 23 Apr 2013 02:46:23 -0700 (PDT)
In-Reply-To: <00F2FE82-F9A7-40AD-B829-6D82C16A75A4@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>
Date: Tue, 23 Apr 2013 02:46:23 -0700
Message-ID: <CAP+FsNe9UNY2Fj+fUA9M8DppmMr0NQ5VYsVCdVi0dddqT4VwBg@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Willy Tarreau <w@1wt.eu>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="089e01494a8aed562404db040e6b"
Received-SPF: pass client-ip=209.85.219.42; envelope-from=grmocg@gmail.com; helo=mail-oa0-f42.google.com
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.726, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UUZoH-0006hq-KY 4b41a596feb293dfe882ac334d11b0d2
X-Original-To: ietf-http-wg@w3.org
Subject: Re: p1: Upgrade ordering (possible HTTP/2 impact)
Archived-At: <http://www.w3.org/mid/CAP+FsNe9UNY2Fj+fUA9M8DppmMr0NQ5VYsVCdVi0dddqT4VwBg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17497
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>

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/
>
>
>
>