> On Dec 8, 2015, at 2: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
Yes. > C. if a protocol supports upgrade on request bodies is up to the protocol > implementation and needs to be checked in the "propose" phase In some respects, yes, but Upgrade is defined by HTTP/1 and no other protocol applies until after it is done. That means ignoring any idiotic handshake requirements of the "new" protocol that aren't consistent with HTTP/1. It also means h2's requirements on Upgrade are irrelevant except for when it requires not upgrading to h2. The client's assumption must be that the Upgrade will fail and any attempt to use Expect will timeout, so the entire message will be sent eventually regardless of anyone's stupid hacks to try and game the protocol. Hence, the server has no choice but to receive the entire message as HTTP/1.1 even if it thinks it could have responded fast enough to interrupt the client in mid-send. > > 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? That seems unlikely. > 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 I think folks are confusing implementation with protocol. There is no need for the protocol being read on a connection to be the same protocol that is being written in response. In other words, the incoming connection remains reading HTTP/1 bits until the message is finished, regardless of the decision to upgrade the response stream -- the other protocol engine doesn't care. This should be easily handled by adding a filter that translates the HTTP/1 incoming body (if any) to a single channel of the new protocol. Just fake it. There is no need to wait or set aside the bytes, unless that is desired for other reasons (e.g., denial of denial of service attacks). > 3. When to do the upgrade dance: > a post_read_request: upgrade precedes authentication > b handler: upgrade only honored on authenticated and otherwise ok requests > c both: introduce separate hooks? have an additional parameter? more > complexity (a). We do want to upgrade non-ok responses. If the "new" protocol wants to send a canned HTTP/1.1 error, it can do so without our help. > 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. Eh? > 5. Will it be possible to migrate the current TLS upgrade handling to this > revised scheme? TLS upgrade is never done with a body (and is broken code anyway). Just fix it. Note that the upgrade token is "TLS" -- it does not have to be "TLS/1.0". ....Roy
