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 01:29:13 GMT
On Tue, Dec 8, 2015 at 1:58 AM, William A Rowe Jr <> wrote:
> On Mon, Dec 7, 2015 at 6:35 PM, Yann Ylavic <> wrote:
>> The body of the first request is never Upgraded, so why would we read
>> it using the Upgraded protocol?
> How do you mean?  The RFC states we must read the request body
> (following a 100-continue) prior to a 101-switching protocols.


> the protocol is switched, we are ready to invoke the handler, which
> will read the request body (which I suggest we have set aside within
> the http input filter) and it will write to the output filter stack, but to
> a different stack of protocol and network filters.

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.
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).
So couldn't we handle the switch (101) in an output filter instead
(before the first bytes are sent)?
Or simply don't honor Upgrade on requests with bodies when it appears
that we'd need to setaside (that would be the case too with
client-to-backend 100-continue and some response available before all
the request body is read, not to speak about the default_handler where
the body is just discarded)?
I think we should try hard to stream things in HTTP/1 too, not
necessarily honor optionals.

View raw message