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.
