HTTP/2 Upgrade with content?

Greg Wilkins <> Thu, 12 March 2015 23:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E053C1A87CD for <>; Thu, 12 Mar 2015 16:13:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.289
X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 q5Xo1Bb2iOU8 for <>; Thu, 12 Mar 2015 16:13:55 -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 D8D1F1A700B for <>; Thu, 12 Mar 2015 16:13:55 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1YWCFP-0003C5-QN for; Thu, 12 Mar 2015 23:10:35 +0000
Resent-Date: Thu, 12 Mar 2015 23:10:35 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.80) (envelope-from <>) id 1YWCFI-0003A2-7s for; Thu, 12 Mar 2015 23:10:28 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1YWCFG-00059O-AQ for; Thu, 12 Mar 2015 23:10:28 +0000
Received: by labhs14 with SMTP id hs14so18627525lab.5 for <>; Thu, 12 Mar 2015 16:09:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=gbdJQDY+ewqmOeQk1Y2Pb1GkBM2Wp7zKau1hNFBQXDY=; b=hYm0oSmLPs+UuJSZ4cqQQMvJPK6NE/jlQNWuEpEYScDmTyX5sRtRY8H/nMOqOYktua EKszhNIAzwrtpyXnNFeBnv+56q3TvRHcjf/ZkE0bi+s8kCrfAxbi1twY1lU2Q6PnN+Bg iY01niVCUyHDSxTHxvSraeHUh6MqIkcousiDIJhF6GNP/0MQwRdsHkKMwEVHMhY78bVJ 5hqEhyA+tbAcoH/hTfN9v/K8IIaT13i78W+qsr35Dig/Gv4thrGYAIiLVeQ4UagO6etF +s5XKk1naBGWnVte4c4jHgqOz/dGFGje390lcrh+JFPr0hMdtgIOmWK3MX9m2vbPCuiy PBLA==
X-Gm-Message-State: ALoCoQnP4eXV32OksfxxmiCJFFChVCzN7pUtuBzsKgFfm2+MA1OzxEFZuImvGD1Hq619VbYAhhKq
MIME-Version: 1.0
X-Received: by with SMTP id q7mr39965716lag.49.1426201799100; Thu, 12 Mar 2015 16:09:59 -0700 (PDT)
Received: by with HTTP; Thu, 12 Mar 2015 16:09:59 -0700 (PDT)
Date: Fri, 13 Mar 2015 10:09:59 +1100
Message-ID: <>
From: Greg Wilkins <>
To: HTTP Working Group <>
Content-Type: multipart/alternative; boundary="089e0160aca49d365f05111f7bbe"
Received-SPF: permerror client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.6
X-W3C-Hub-Spam-Report: AWL=-2.918, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001
X-W3C-Scan-Sig: 1YWCFG-00059O-AQ 415283f99f8fd9fecee3f75e3b55b3bf
Subject: HTTP/2 Upgrade with content?
Archived-At: <>
X-Mailing-List: <> archive/latest/28945
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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

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

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.