On Mon, Dec 7, 2015 at 6:35 PM, Yann Ylavic <ylavic....@gmail.com> wrote:
> On Tue, Dec 8, 2015 at 1:27 AM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > On Mon, Dec 7, 2015 at 6:15 PM, Yann Ylavic <ylavic....@gmail.com> > wrote: > >> > >> On Tue, Dec 8, 2015 at 1:07 AM, Yann Ylavic <ylavic....@gmail.com> > wrote: > >> > > >> > the body ought to be > >> > set aside for any (relevant) TLS response (which needs the > >> > handshake...). > >> > >> Hmm, no need to set aside, *unless* with must produce a response > >> before the entire body (and the handshake) is read. > >> But we'd better not Upgrade in this case... > > > > > > Yes, there is a set aside, because the handler will read from the filter > > stack... the handler phase has not yet occurred, and other content > > input filters may be inserted to transform the request body. > > > > The upgrade switch would occur before the request content handler > > is invoked, in all cases (post_read_request, or later during fixups > > or the very beginning of invoke_handler). > > But this isn't what the RFC says, right? > 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. 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. Depending on the protocol, it may have to perform some magic to move the (smaller) request body over to a new protocol if the http/1.1 filter will no longer be in the stack. If the request body can't be set aside while still speaking http/1.1 (buffer too small, etc) then in that case we cannot honor the upgrade: request or switch protocols at all.
