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