ok, after some more thinking. if a tls+http/1.1 upgrade together with Expect is indeed a use case, then, to make that work, sending the 101 needs to become the task of the switch protocol handler itself. Then the order in which intermediate responses are sent depends on the switched protocol.
When writing the current code, I wanted the common tasks in core. But if that needs to vary, we need to shift that. > Am 07.12.2015 um 21:39 schrieb Stefan Eissing <stefan.eiss...@greenbytes.de>: > > 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. >> >> >> >>
