There can be no 100 after a 101. After a 101, the downstream speaks the new protocol, immediately.
> Am 07.12.2015 um 21:29 schrieb William A Rowe Jr <wr...@rowe-clan.net>: > >> On Mon, Dec 7, 2015 at 2:15 PM, Jacob Champion <champio...@gmail.com> wrote: >> On Dec 7, 2015 8:43 AM, "William A Rowe Jr" <wr...@rowe-clan.net> wrote: >> > >> > https://tools.ietf.org/html/rfc7230#section-6.7 makes things more >> > interesting, it calls out that 101-continue and the request body read >> > precedes the 101-switching protocols. Not sure who decided that would be >> > a good idea, sigh... >> >> 100-continue can't be after the switch; the new protocol may not have any >> idea what continue semantics are. Similarly, the request body sent is still >> part of an HTTP/1.1 request and should be processed as such. >> >> > but mod_ssl TLS upgrade has these reversed for several good reasons >> > including the intent to encrypt the request body if present and simple >> > economics of processing. >> >> Did you mean "decrypt the request body"? >> > Yes, my bad... >> The client needs to send its request body in plaintext since servers are >> free to completely ignore the Upgrade, right? My reading of the specs is >> that an Upgrade request is still a self-contained HTTP/1.1 request, body >> included. >> > No. If the upgrade is rejected, no 101-switching protocols occurs. If there > was no Expect: 100-continue then yes, the body seems part of the request > headers with no way to anticipate how to proceed except plaintext, but in the > case of an Expect: 100-continue, an an interim 101-switching protocols, a tls > handshake, followed by a 100-continue seemed entirely reasonable. > > It appears we did the wrong thing in the absence of an Expect: 100-continue, > but as a practical matter this seems fairly academic since RFC7230 codifies a > specific sequence that we must adopt, and the instances of request bodies in > upgrade requests seems philosophical. > > > >
