On Tue, Dec 8, 2015 at 1:58 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Mon, Dec 7, 2015 at 6:35 PM, Yann Ylavic <ylavic....@gmail.com> wrote: >> >> The body of the first request is never Upgraded, so why would we read >> it using the Upgraded protocol? > > > How do you mean? The RFC states we must read the request body > (following a 100-continue) prior to a 101-switching protocols.
Right. > AFTER > the protocol is switched, we are ready to invoke the handler, which > will read the request body (which I suggest we have set aside within > the http input filter) and it will write to the output filter stack, but to > a different stack of protocol and network filters. The handler handling the first request has to read the body before the switch, eg. mod_proxy could forward the request without the client having switched to any other protocol. That does not mean it has to (or prereqs a) setaside body, this could be streamed (and is even desirable in the mod_proxy case). So couldn't we handle the switch (101) in an output filter instead (before the first bytes are sent)? Or simply don't honor Upgrade on requests with bodies when it appears that we'd need to setaside (that would be the case too with client-to-backend 100-continue and some response available before all the request body is read, not to speak about the default_handler where the body is just discarded)? I think we should try hard to stream things in HTTP/1 too, not necessarily honor optionals.
