httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgrade tls
Date Tue, 08 Dec 2015 00:07:45 GMT
On Mon, Dec 7, 2015 at 5:38 PM, William A Rowe Jr <wrowe@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).

Mime
View raw message