On Tue, Dec 8, 2015 at 11:07 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> wrote: > Trying to summarize the status of the discussion and where the issues are > with the current Upgrade implementation. > > Clarified: > A. any 100 must be sent out *before* a 101 response > B. request bodies are to be read in the original protocol, input filters like > chunk can be used, indeed are necessary, as if the request is being processed > normally > C. if a protocol supports upgrade on request bodies is up to the protocol > implementation and needs to be checked in the "propose" phase
Agreed. > > 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? > 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? > c both: introduce separate hooks? have an additional parameter? more > complexity Depends on whether OPTIONS (others?) need special treatment. > 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. > > 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.
