Re: HTTP/2 Upgrade with content?

Stefan Eissing <> Fri, 13 March 2015 14:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D17AE1A896B for <>; Fri, 13 Mar 2015 07:26:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Zi4kasnaQiA3 for <>; Fri, 13 Mar 2015 07:26:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 359BA1A8958 for <>; Fri, 13 Mar 2015 07:26:10 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1YWQTu-0004C5-EQ for; Fri, 13 Mar 2015 14:22:30 +0000
Resent-Date: Fri, 13 Mar 2015 14:22:30 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.80) (envelope-from <>) id 1YWQTn-0004Af-6g for; Fri, 13 Mar 2015 14:22:23 +0000
Received: from ([]) by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <>) id 1YWQTi-0003gh-H7 for; Fri, 13 Mar 2015 14:22:23 +0000
Received: from (unknown []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id B375A15A0327; Fri, 13 Mar 2015 15:21:55 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Stefan Eissing <>
In-Reply-To: <>
Date: Fri, 13 Mar 2015 15:21:55 +0100
Cc: Greg Wilkins <>, "Jason T. Greene" <>, Mike Bishop <>, HTTP Working Group <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Daniel Stenberg <>
X-Mailer: Apple Mail (2.2070.6)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.1
X-W3C-Hub-Spam-Report: AWL=-3.112, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001
X-W3C-Scan-Sig: 1YWQTi-0003gh-H7 f3d07733d98dea35c69e4211c62e23aa
Subject: Re: HTTP/2 Upgrade with content?
Archived-At: <>
X-Mailing-List: <> archive/latest/28963
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Well, this discussion quickly dove into the quantum foam between specification and deployed software.

I take away from it:
- that protocol switching happens immediately after the 101 response - for the downstream. On the upstream it switches after the request has been read. Pretty obvious in hindsight, as those things are.
- servers should be predictable in upgrading, either always with content or only without.
- the common use case for upgrade on POST does not benefit from h2c and this it seems not worth the effort to implement. Fullfilling the request on HTTP/1.1 format seems to work fine.
- maybe a mixed 1.1 up and h2c down request could be made to work, but there seems no gain for anyone in creating this mythical beast.


> Am 13.03.2015 um 15:04 schrieb Daniel Stenberg <>:
> On Sat, 14 Mar 2015, Greg Wilkins wrote:
>>> Why not attempt a PRI with the explicit http2 option?
>> Yes that would be a lot better and we already support it in jetty.
> Sure, curl will support that too soon but I think that is beside the point. In this case users can use this option on virtually any server without knowing whether it supports version 2 or not. Like Upgrade: is supposed to work!
>> The issue with the curl usecase using upgrade is that all the upgrade work
>> is essentially wasted effort - as the bulk upload is done with HTTP/1.1,
> Yes, but... for example, what if that is the first operation out of several, and then once the first operation has updated to version 2 all the subsequent ones can continue using HTTP/2. And since the upgrade, it would just work with 1.1 servers as we all as 2 servers without the client having to know before-hand.
> And in the end, we usually allow curl to exercise every possible protocol option that is valid (and sometimes also a few that aren't valid) to allow people like readers of this list to test out and torture our own and others servers!

I think they call it "enhanced interrogation" nowadays.

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782