httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgrade tls
Date Mon, 07 Dec 2015 20:29:15 GMT
On Mon, Dec 7, 2015 at 2:15 PM, Jacob Champion <champion.p@gmail.com> wrote:

> On Dec 7, 2015 8:43 AM, "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...
>
> 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.

Mime
View raw message