Well.... 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 specs.
> On Dec 8, 2015, at 3:22 PM, Jacob Champion <[email protected]> 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 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
