W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2015

Re: HTTP/2 Upgrade with content?

From: Jason T. Greene <jason.greene@redhat.com>
Date: Fri, 13 Mar 2015 04:28:46 -0400 (EDT)
Message-Id: <7C1D0B76-0C00-4BF4-B2D2-EE0D311B75A0@redhat.com>
To: Greg Wilkins <gregw@intalio.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
What about draining the content and after the 101 the h2 response sends a 307?

> On Mar 12, 2015, at 6:14 PM, Greg Wilkins <gregw@intalio.com> wrote:
> 
> 
> 
> 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 Friday, 13 March 2015 08:29:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:36 UTC