httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Champion <>
Subject On the Upgrade request body limit
Date Tue, 08 Dec 2015 20:22:17 GMT
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 that

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 limited?

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 

Or is the correct "fix" to rearchitect so the limit during upgrades can 
be exactly the same as during a normal request?


View raw message