RE: HTTP/2 Upgrade with content?

Mike Bishop <> Thu, 12 March 2015 23:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 053AD1A8850 for <>; Thu, 12 Mar 2015 16:50:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 WWcELVgA1QqR for <>; Thu, 12 Mar 2015 16:50:48 -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 AA9D31A884B for <>; Thu, 12 Mar 2015 16:50:48 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1YWCpO-0003NX-UA for; Thu, 12 Mar 2015 23:47:46 +0000
Resent-Date: Thu, 12 Mar 2015 23:47:46 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.80) (envelope-from <>) id 1YWCpG-0003L2-Qj for; Thu, 12 Mar 2015 23:47:38 +0000
Received: from ([] by with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <>) id 1YWCpB-0006XS-1C for; Thu, 12 Mar 2015 23:47:38 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 12 Mar 2015 23:47:06 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 12 Mar 2015 23:47:05 +0000
Received: from ([]) by ([]) with mapi id 15.01.0106.007; Thu, 12 Mar 2015 23:47:05 +0000
From: Mike Bishop <>
To: Greg Wilkins <>, HTTP Working Group <>
Thread-Topic: HTTP/2 Upgrade with content?
Thread-Index: AQHQXRpK+kumJXF4/kG2MKCIGYLanJ0ZgfjA
Date: Thu, 12 Mar 2015 23:47:05 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: [2001:4898:80e8:ed31::3]
authentication-results:; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB129; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB563;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(377454003)(46102003)(74316001)(19609705001)(19580395003)(19580405001)(122556002)(2950100001)(2900100001)(102836002)(15975445007)(92566002)(77156002)(62966003)(40100003)(19300405004)(16601075003)(106116001)(107886001)(99286002)(54356999)(76176999)(50986999)(76576001)(16236675004)(15395725005)(2656002)(87936001)(19625215002)(33656002)(86612001)(86362001)(19617315012)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB129;; FPR:; SPF:None; MLV:sfv; LANG:en;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:BL2PR03MB129; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB129;
x-forefront-prvs: 05134F8B4F
Content-Type: multipart/alternative; boundary="_000_BL2PR03MB1323474B977B051738AD09187060BL2PR03MB132namprd_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2015 23:47:05.5361 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB129
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.1
X-W3C-Hub-Spam-Report: AWL=-3.138, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001
X-W3C-Scan-Sig: 1YWCpB-0006XS-1C 6cb28dd59fd9885d0b4aadfa69f11434
Subject: RE: HTTP/2 Upgrade with content?
Archived-At: <>
X-Mailing-List: <> archive/latest/28946
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

A server is blocked on the connection, just as it would be in HTTP/1.1.  The situation for the server is no worse than if the client weren’t offering Upgrade.  Servers will enforce the same limits of large bodies they’re not willing to handle.  Issuing a 413, telling the client that the reason their request isn’t being serviced is due to the size of the body, is confusing if the actual way to make it be serviced is to omit the Upgrade header.  That’s a bizarre use of 413.

My inclination would be for servers to ignore the Upgrade header if they don’t want to be blocked.  Clients will always need to handle Upgrade headers being ignored, since they can legitimately be stripped by intermediaries.  Clients will never understand all the reasons why some Upgrades work and some don’t – they have to handle both cases cleanly.

From: Greg Wilkins []
Sent: Thursday, March 12, 2015 4:10 PM
To: HTTP Working Group
Subject: HTTP/2 Upgrade with content?

Section 3.2 describes the upgrade to HTTP/2 and it allows support for upgrade requests with bodies:

   Requests that contain an entity body MUST be sent in their entirety

   before the client can send HTTP/2 frames. This means that a large

   request entity can block the use of the connection until it is

   completely sent.
Servers will need to protect themselves from DoS attacks via such requests as buffering arbitrary large content in their entirety is a commitment that servers cannot generally give.
Thus servers will have to limit the size of the entities they are prepared to hold in this situation (and the size of a single normal request buffers is probably the memory commitment they are prepared to make for any given connection).

My question is, what should a server do if it receives an otherwise valid upgrade request that it could handle but with content that exceeds this memory limit?      Should it respond with a 413 REQUEST_ENTITY_TOO_LARGE or should it just ignore the upgrade and let the request be handled via HTTP/1.1 (which can stream the content into the request handler and it becomes somebody else's problem to limit memory usage).
My problem with ignoring the upgrade is that it is an arbitrary limit and it will be hard for clients to tell why some upgrades work and others do not.
Alternately my problem with 413 is that some servers might wish to avoid the whole upgrade with content path and thus send a 413 for any upgrade with content, which may break some clients that could otherwise proceed with HTTP/1.1

PS. in hindsight, I would rather that we had not allowed upgrades with content and instead told clients to upgrade with an OPTION request prior to any PUT/POST request.... gallop... gallop... gallop.... SLAM!

Greg Wilkins <<>>  @  Webtide - an Intalio subsidiary HTTP, SPDY, Websocket server and client that scales  advice and support for jetty and cometd.