On Mon, Dec 7, 2015 at 2:39 PM, Stefan Eissing <stefan.eiss...@greenbytes.de > wrote:
> There can be no 100 after a 101. After a 101, the downstream speaks the > new protocol, immediately. > Right, and the new protocol is TLS/1.x HTTP/1.1 in the mod_ssl case. What's so confusing? > 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. > > > > >
