Wow, you have been busy in my sleep... I will respond to individual messages later in my office. From what I got overall:
- I completely agree with Yann, request bodies, 100 continue or not, are sent using the original, pre-upgrade protocol, e.g. http/1.1 - until the body is read, 101 may be sent back, but afterwards the downstream is talking the new protocol, while the upstream can only start doing so after the last request byte - this makes upgrades on requests with bodies awkward for both parties. the approach of setaside nnn bytes is bad for interop as there is no standard what nnn is supposed to be, leading to failed requests varying by implementation or even size specific configuration. For h2 therfore all server implementors on the HTTP WG list at that time agreed to body-less upgrades only. - In case a client wants to talk to a known server implementation and is concerned about efficiency, I'd recommend http2 direct mode. 24 initial bytes and you have http2. - as Jacob pointed out, some protocols need deeper inspections/other responses before sending out 101. So, I think making that part of the protocol switch handler is better. //Stefan > Am 08.12.2015 um 03:50 schrieb William A Rowe Jr <wr...@rowe-clan.net>: > > 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. > > > >
