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
entirely?
Or is the correct "fix" to rearchitect so the limit during upgrades can
be exactly the same as during a normal request?
--Jacob
