httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: On the Upgrade request body limit
Date Tue, 08 Dec 2015 20:45:20 GMT

We are not NGINX. We are also not Microsoft. We don't create HTTP
response codes willy-nilly. We actually try to *honor* the actual

> On Dec 8, 2015, at 3:22 PM, Jacob Champion <> wrote:
> I wrote this in response to Stefan's note on the zero-length request body limit for h2c
Upgrades, then realized it would further fragment the (already massive) conversation, so here
it is.
> Stefan wrote:
>> It is possible, but difficult to do unless you can read the body and
> > set it aside somewhere. Which again imposes an arbitrary (for the
> > client) limit. Experience shows that this leads to design of clients
> > that work will in developments, but then encounter requests
> > usage/sites/servers that have other limits and break.
> This is true of other things about HTTP/1.1 too -- how does a client figure out what
the maximum request size for a server is? -- but it's made harder in this case by the fact
> 1) 100 Continue is sent whether the request is upgraded or not, which makes it impossible
to use a continue handshake to quickly determine upgrade limits, and
> 2) returning 413 during an upgrade would be ambiguous anyway. Is the 413 really related
to the request target, or is it just because I tried to upgrade and my request was temporarily
> It seems to me that we're missing something in HTTP/1.1 that would make these complex
Upgrade scenarios robust. IIUC, the point of allowing request bodies during upgrades was to
decrease the number of round trips, but if implementations can't actually make use of it in
practice then that's not very useful...
> If it were enough of a problem to fix (and I'm not claiming it is, necessarily), how
would we fix it? Would we need a new 1xx response (e.g. 103 Upgrade Declined, with headers
indicating the related protocol and the reason for the failure)? A new header in OPTIONS?
Something else entirely?
> Or is the correct "fix" to rearchitect so the limit during upgrades can be exactly the
same as during a normal request?
> --Jacob

View raw message