httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <stefan.eiss...@greenbytes.de>
Subject Re: 2.4 pause - mod_http2 patchset Upgrade h2c vs mod_ssl Upgrade tls
Date Tue, 08 Dec 2015 09:25:04 GMT

> Am 08.12.2015 um 01:58 schrieb William A Rowe Jr <wrowe@rowe-clan.net>:
> 
> On Mon, Dec 7, 2015 at 6:35 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
> On Tue, Dec 8, 2015 at 1:27 AM, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
> > On Mon, Dec 7, 2015 at 6:15 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
> >>
> >> On Tue, Dec 8, 2015 at 1:07 AM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
> >> >
> >> > the body ought to be
> >> > set aside for any (relevant) TLS response (which needs the
> >> > handshake...).
> >>
> >> Hmm, no need to set aside, *unless* with must produce a response
> >> before the entire body (and the handshake) is read.
> >> But we'd better not Upgrade in this case...
> >
> >
> > Yes, there is a set aside, because the handler will read from the filter
> > stack... the handler phase has not yet occurred, and other content
> > input filters may be inserted to transform the request body.
> >
> > The upgrade switch would occur before the request content handler
> > is invoked, in all cases (post_read_request, or later during fixups
> > or the very beginning of invoke_handler).
> 
> But this isn't what the RFC says, right?
> 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.  AFTER
> 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.

No, that is not what the RFC says. HTTP/1 switching protocols does not need
to happen simultaneously on upstream and downstream. Instead, the server
switches directly after the 101 response, the client switches after the last
byte of the request.

This is problematic for protocols like HTTP/2 who may require to receive
data in the new protocol format *before* they are able to read an arbitrarily
long request body. So, every HTTP/2 implementation will have a request
body maximum length that it can upgrade with. For interop reasons, me and
other implementors choose to have 0 as max length, since every clients
will run into that limit immediately and learn to cope with that.

Please remember that such a request will be answered correctly and that 
the client can upgrade to h2c on the next one, or anytime it likes. The
upgrade possibilities are announced by Apache on the first response, so
it should be easy to make a decision.

//Stefan



Mime
View raw message