> Am 08.12.2015 um 11:44 schrieb Yann Ylavic <ylavic....@gmail.com>: > > On Tue, Dec 8, 2015 at 11:07 AM, Stefan Eissing > <stefan.eiss...@greenbytes.de> wrote: >> [...] >> Open: >> 1. Protocols like Websocket need to take over the 101 sending themselves in >> the "switch protocol" phase. (correct, Jacob?). Should we delegate the >> sending of the 101 to the protocol switch handler? >> 2. General handling of request bodies. Options: >> a setaside in core of up to nnn bytes before switch invocation >> b do nothing, let protocol switch handler care about it > > a. is tempting, where nnn would be the limit above which we don't honor > Upgrade. > But that could be a default behaviour, i.e. when "Protocols ... http1" > is finally elected. > Possibly specific modules would bypass that? > >> 3. When to do the upgrade dance: >> a post_read_request: upgrade precedes authentication > > Looks like it can't be RFC compliant, is it?
I think it will not be, right. >> b handler: upgrade only honored on authenticated and otherwise ok requests > > This is probably the right thing to do, would OPTIONS be special is this case? It currently is insofar as core installs a storage handler to invoke the, otherwise same, upgrade handling code. It's a special case, but nothing the protocol handlers need to care about... >> c both: introduce separate hooks? have an additional parameter? more >> complexity > > Depends on whether OPTIONS (others?) need special treatment. The current design works with it while exposing in the API only one set of hooks. If those get called from one or the other does not matter. For each request, the hooks are invoked at most once. >> 4. status code of protocol switch handler: if we move the task of 101 >> sending, the switch handler might not do it and keep the connection on the >> "old" protocol. Then a connection close is not necessary. So, we would do >> the close only when the switch handler returns APR_EOF. >> 5. Will it be possible to migrate the current TLS upgrade handling to this >> revised scheme? > > We must do that IMHO, the scheme should be suite for all the cases. Agreed. >> PS. Re 5: with change 1+4, a TLS upgrade switcher could install an output >> filter, return and have it being processed normally. The output filter would >> then send the 101 and do the TLS handshake. Would that work? > > The issue is that this output filter would have to both read and write > during the TLS handshake, not sure this is suitable. Ok, maybe from pre_read_request hook then?
