httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <>
Subject Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgrade tls
Date Tue, 08 Dec 2015 09:48:01 GMT
On Tue, Dec 8, 2015 at 3:07 AM, William A Rowe Jr <> wrote:
>> The handler handling the first request has to read the body before the
>> switch, eg. mod_proxy could forward the request without the client
>> having switched to any other protocol.
> Whoa... First the handler can't process the request until the switch, and
> more importantly the protocol upgrade is hop by hop, review s6.7 again
> please.

Hop by hop does not mean that Upgrade has to be done as soon as
possible, but that it must not be forwarded (this is client <=> httpd
stuff only, any the backend/origin wouldn't notice).

The handler has to process an HTTP/1 body (that is, plain text when
http: is used), because this is what the client will send (s6.7 states
that the first request is HTTP/1, including the body, IOW the client
can't change that between the header and the body).
So if we were to set aside the first request body on Upgrade, do the
switch, and then run the handler, the latter should not expect
anything else than HTTP/1 for the body (this is how the body is, be it
aside or not).

Moreover, if we choose to honor the Upgrade after the body, we must
produce a response which is Upgraded, that means for the TLS/1.x case
that we must first enable mod_ssl, read/write/do the TLS handshake so
that the response is really TLS/1.x upgraded.
We can indeed do that by reading/setaside the body, send the 101
switch to the client, do the handshake, play the setaside HTTP/1 body
through the input filter, and finally be HTTP/1+TLS on the (first)
response and further requests.
But I find this a bit complicated, not to talk about resources usage /
possible DOS...

> The mechanism to address your use case is HTTP/1.1 CONNECT.

My use case is a normal HTTP/1 request with a body, w/ or w/o
100-continue, through mod_proxy_http, not CONNECT.
And I don't want Upgrade to break or make this overly complicated.

>> That does not mean it has to (or prereqs a) setaside body, this could
>> be streamed (and is even desirable in the mod_proxy case).
> Not possible to read plaintext and write TLS, for example.  The body must be
> consumed first.

The HTTP/1 Upgrade described in the RFC is actually "read plaintext
and write TLS", AIUI.

>> So couldn't we handle the switch (101) in an output filter instead
>> (before the first bytes are sent)?
> No, for TLS, absolutely not.
> You presume the handler consumed the body, and you have no assurance of
> that.  Which means the output filter now needs to attend to the input filter
> state, and we are back where we started with the no 101 before the upgrade
> can be satisfied.

That's why I'd rather go with *not* honoring the Upgrade until a
request comes with no body.

View raw message