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 Tue, 08 Dec 2015 02:07:34 GMT
On Dec 7, 2015 19:29, "Yann Ylavic" <ylavic.dev@gmail.com> wrote:
>
> On Tue, Dec 8, 2015 at 1:58 AM, William A Rowe Jr <wrowe@rowe-clan.net>
wrote:
> > On Mon, Dec 7, 2015 at 6:35 PM, Yann Ylavic <ylavic.dev@gmail.com>
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.
>
> Right.
>
> > 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.
>
> 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.

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

In terms of h2/h2c/HTTP/https the connection between user agent and gateway
has no bearing on the connection to the back end in the reverse proxy
situation.

> 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.

> 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.

If the upgrade fails (tls handshake failure or whatnot) we have no
intention of starting a stateful transaction that will be broken.  No
successful upgrade, then no handler invocation.

And if the handler wants to make an election based on the protocol, it
cannot do this before reading all the input.  Sub-optimal if not simply
broken.

And as I've called out already the entire pre-handler cycle needs to be
able to inspect the tls session for authn/authz.

> 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.

What's the performance impact of a 16k or 64k set aside?  None, those
buckets would have been called up anyways without the protocol switch.  We
are streaming, some baseline buckets must always be filled in all cases.
The extent of that buffer can be administor controlled.

The call is out there from svn, and many other web services will eventually
rely on the same concept, this is a must have to avoid the very round trips
that h2c sought to avoid.

Mime
View raw message