On Mon, Dec 7, 2015 at 5:38 PM, 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... 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.
As I read rfc7230#section-6.7 : A client cannot begin using an upgraded protocol on the connection until it has completely sent the request message (i.e., the client can't change the protocol it is sending in the middle of a message). the server is supposed to respond with a 101 and than the Upgrade'd response (using the Upgrade protocol, eg. TLS/1.x), but *after* the request body is read (in plain text!). That means, for the TLS/1.x case, that the client handshake is supposed to arrive after a request body (if any), and hence mod_ssl can't assume the first request body is TLS'd, and the body ought to be set aside for any (relevant) TLS response (which needs the handshake...). I don't see this is working like this in mod_ssl, am I missing something ? Still rfc7230#section-6.7: If a server receives both an Upgrade and an Expect header field with the "100-continue" expectation (Section 5.1.1 of [RFC7231]), the server MUST send a 100 (Continue) response before sending a 101 (Switching Protocols) response. The 100-continue case isn't a particular one IMHO, any Upgrade header would be informative, not authoritative (not a 101 status).
