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:50:05 GMT
Sorry it took so long to respond to this earlier post, some of this might
have already been covered...

On Mon, Dec 7, 2015 at 1:03 PM, Stefan Eissing <stefan.eissing@greenbytes.de
> wrote:

>
>
Think about CORS restrictions and other stuff.
> - I think its the protocol handlers job to deal with any request body.
>

Strongly disagree, because 1. the protocol switch mechansim isn't the
content handler of the originating request, the request body is a
request-level entity, and 2. TLS gave you a perfect illustration of
altering the connection stack to continue using the core protocol stack.

In the case of h2c, or even a mod_echo Upgrade: echo mechanism, the entire
request/response is going to be handed off to a new protocol stack, I
understand that.  But that is one of several use cases here, and that new
protocol stack is going to consume the network pipe and close it, I
trust?!?  And return the appropriate status that the connection is gone
even if it leaves the old code to mop up, e.g. lingering_close.

For h2 upgrade, for example, the switch is only offered for requests
> without body.
>

Well, h2c is advertised on the first request with or without a body, and
then never again. Other modules must advertise, e.g. in conjunction with
the 426 Upgrade Required.

In fact, how do you propose to handle an authentication case with h2c
living in near the handler phase, when it will alert during the authnz
phase that http1.1 has been disallowed/h2c is required for a particular
resource, and that upgrade (which could have occurred in the
post-read-request phase) has not yet occurred during auth?

- moving things to post read sounds tempting, however I'm not sure if we
> want to upgrade on non-authed request or not, for example.
>

This is transport layer, yes, we always address the protocol without
consideration as to authnz; the same as we decode gzip irrespective of
client auth.  The actual requests over h2c (or http/1.1) are *each* still
subject to auth per-request.

I can't see a justification for excluding a client other than the user
agent identifier (known inoperable agent), otherwise h2c benefits the
client-server performance and there is no obvious reason to prevent it?


> I am not sure what else we do in post read, maybe someone else has an
> opinion about that. It certainly looks nicer in the OPTIONS * case.
>

The most critical thing for all of us to pay attention to is the setenvif
logic and mod_headers injection, things that are there to deliberately
affect the initial read and processing of.  The admin may want to trick
httpd into *not* honoring upgrades from specific user agent signatures that
are known-wonky, or when other request headers are present.  So I suggested
HOOK_LAST, although a slightly different order could work.  We carefully
inject mod_ssl (not upgrade, but the core read request hook) to fall after
mod_setenvif, but otherwise at HOOK_MIDDLE.

Mime
View raw message