- From: Greg Wilkins <gregw@intalio.com>
- Date: Fri, 13 Mar 2015 10:09:59 +1100
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAH_y2NF3iwND1ttQDY98KC_u=OZj5aqEABmXHKObMgqPH1npLg@mail.gmail.com>
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 thoughts? 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 <gregw@intalio.com> @ Webtide - *an Intalio subsidiary* http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales http://www.webtide.com advice and support for jetty and cometd.
Received on Thursday, 12 March 2015 23:10:28 UTC