On Mon, Dec 7, 2015 at 6:07 PM, Yann Ylavic <ylavic....@gmail.com> wrote:
> 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 ? > Yes you are missing the relevant design spec, RFC2817, now superseded in part, in conjunction with RFC2616. The behavior has to change, and my generalized proposal is in the message immediately preceding this reply. > 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). > Not sure what you mean. If an Upgrade: request is recieved and declined, you are right, there is no 101-switching protocols, just the typical http/1.1 response following any 100-continue negotiated request body.
