Re: Is the response header "Upgrade: h2" allowed when TLS is used?

Cory Benfield <cory@lukasa.co.uk> Tue, 19 April 2016 15:34 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 0011B12DC26 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 19 Apr 2016 08:34:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.917
X-Spam-Level:
X-Spam-Status: No, score=-7.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lukasa-co-uk.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YqVPrKso6si for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 19 Apr 2016 08:34:55 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A11312DBDE for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 19 Apr 2016 08:34:55 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1asXbm-0003jk-Tk for ietf-http-wg-dist@listhub.w3.org; Tue, 19 Apr 2016 15:30:34 +0000
Resent-Date: Tue, 19 Apr 2016 15:30:34 +0000
Resent-Message-Id: <E1asXbm-0003jk-Tk@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <cory@lukasa.co.uk>) id 1asXbf-0003bT-GD for ietf-http-wg@listhub.w3.org; Tue, 19 Apr 2016 15:30:27 +0000
Received: from mail-wm0-f46.google.com ([74.125.82.46]) by maggie.w3.org with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <cory@lukasa.co.uk>) id 1asXbc-0001zE-Cb for ietf-http-wg@w3.org; Tue, 19 Apr 2016 15:30:27 +0000
Received: by mail-wm0-f46.google.com with SMTP id u206so36057099wme.1 for <ietf-http-wg@w3.org>; Tue, 19 Apr 2016 08:30:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lukasa-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=n0yWbUp8lLmsFA8kMy/oljd0zsGkdA96FuX29FdQo9A=; b=gnkI+dfL0BShACQKS120Pox8ZKMGx8+IlxfrbbRZ5wOeYmgSQ0INydnC0EMSN70g1K dii4fRSXf+DECuxISvvuKy/X8/F4uWSuAaK/UgSXF+vDdaDXF593IXyj7g2Q0jfcOfmR UqZw3YN3RrmgRCYv3IIExBJmRXbJhzfdlQ6VRZgZbgkqxmNRUV+lFKSL8SmbQoHTkUbG FddOALOBb++n8WM+ymUVzU6UFfh3r6VWbwkoDJlfpAx3PoHm7+lrktNFyhFn1WNEPwQ6 bU4er6DGEDOycgavwvhJ9uAbsw5W2pdt9MV9j0nMouRjn306C91R7R+ECQ18/PfLDx32 zp4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=n0yWbUp8lLmsFA8kMy/oljd0zsGkdA96FuX29FdQo9A=; b=cbVJywSEgSJd697rRWMB8c/KP+5011wjYH0Xwgq3wbkZntCK916Zfxgin6r/4LCfxx rbPyyzkuKB6hPH2hlRIp7vGLCpOQb9Npt+LtRcYU/VQhTRCvMnCY2diQpbauBEzk8VWd D8jkq/niv0grKxnvqace4YSAIpBle8pNAaq7gM1Sl0AlmuGe55nPTljGrUbCFBuCAPzJ IR2SA1Qoz1HHpeep4gaekQgEybeTltdQ5PclxyiOCIA5WzTwfXyeJyVuV4l5c5aQz0iu 3e4tIzqZXPmqpUw7DNM3KCPVLD+ve5Wi7OrphYYhmYb6iX1wqOyR+4GFtQxmNj1JeHh2 KIrQ==
X-Gm-Message-State: AOPr4FXLoNVhSOGa607dA9ABfF7ZB9+x9v8G+x39D5S1LiAgiJXIxrGz2wtIOvhvMCed/g==
X-Received: by 10.194.140.17 with SMTP id rc17mr4339122wjb.175.1461079797469; Tue, 19 Apr 2016 08:29:57 -0700 (PDT)
Received: from [192.168.1.6] (41.65.125.91.dyn.plus.net. [91.125.65.41]) by smtp.gmail.com with ESMTPSA id g141sm4943699wme.0.2016.04.19.08.29.56 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Apr 2016 08:29:56 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_55471446-70D9-435D-86B8-D51C0C3C82CE"; protocol="application/pgp-signature"; micalg="pgp-sha256"
X-Pgp-Agent: GPGMail 2.6b2
From: Cory Benfield <cory@lukasa.co.uk>
In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A2A7CBD72@bgb01xud1012>
Date: Tue, 19 Apr 2016 16:29:54 +0100
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-Id: <BE75D624-3A89-463A-B860-A2E83613C199@lukasa.co.uk>
References: <20160419161634.Horde.7_VYZk5McZE4CAiQrQh-uXr@webmail.michael-kaufmann.ch> <7CF7F94CB496BF4FAB1676F375F9666A2A7CBD72@bgb01xud1012>
To: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
X-Mailer: Apple Mail (2.3124)
Received-SPF: pass client-ip=74.125.82.46; envelope-from=cory@lukasa.co.uk; helo=mail-wm0-f46.google.com
X-W3C-Hub-Spam-Status: No, score=-4.6
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1asXbc-0001zE-Cb 9f760dd2561bc1c796556cd47b21fe79
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Is the response header "Upgrade: h2" allowed when TLS is used?
Archived-At: <http://www.w3.org/mid/BE75D624-3A89-463A-B860-A2E83613C199@lukasa.co.uk>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31507
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 19 Apr 2016, at 16:16, Lucas Pardue <Lucas.Pardue@bbc.co.uk> wrote:
> 
> Stefan and Daniel point out that the server uses the Upgrade header to "advertise support" for h2. RFC 7230 Section 6.7 [5] states that the server MAY send the Upgrade header. It seems to me like Apache is technically compliant. On an https connection this information shouldn't be used to perform an HTTP upgrade to h2, since that is invalid (but a client issue not a server one). On an http connection the info could be used by the client e.g. they decide to negotiate an h2 session using ALPN.

I don’t think that’s really a good way to read this section of RFC 7230. The first sentence in this section is '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.’. Note that phrase “on the same connection”. I’d argue, based on that, that the server-sent Upgrade header should only list protocols that the server is willing to upgrade to *on that connection*.

If Apache is willing to do the HTTP/2 upgrade dance from a TLS’d HTTP1.1 connection, I’d say that this argument makes sense. Otherwise, I don’t think it does: the client needs to use a new connection, which means the Upgrade header isn’t appropriate. This use-case is satisfied by RFC 7838’s HTTP Alternative Services: Apache should use that header instead, rather than this Upgrade header.

For what it’s worth, as far as I can see RFC 7540 doesn’t *forbid* doing the Upgrade dance on a TLS’d HTTP/1.1 connection: it just says nothing about it. There’s no normative language in RFC 7540 that says that we MUST use ALPN for “https” URLs, it only says that clients *do* that. I’d say that you can read that as saying that a client MUST implement *at least* support for that, but may also implement support for alternative negotiation means (e.g. HTTP Upgrade).

Cory