On 9 Dec 2015, at 23:19, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> Because the request body is inbound already at some state of completion > or incomplete transmission, it is competing with the TLS handshake, which > is a bidirectional engagement with the same socket between the user agent > and server. Unlike h2c and websocket, where Roy suggests we leave the > http/1 input filter in place and inject the http/2 output filter for the > duration > of the initial Upgrade: request, we must pass TLS traffic in both directions > at once during Upgrade: TLS. … > Please remember that a request handler is based on a method and location, > while Upgrade is not the request itself, but a proposal to switch protocols. > In the case of TLS and h2c, that request is satisfied over the corresponding > HTTP/1 or HTTP/2 output filter, but I'm not clear whether websocket has > any equivalence in terms of a content handler phase. In a sense, all upgrades happen after of an existing request (& response). So how about this high level behaviour model: httpd keeps note, for each connection, of what upgrades are (1) feasible and (2) agreed upon. At end of any given request, either zero or one of the feasible upgrades will have been agreed between web server and client. That's when the upgrade should happen if it has been negotiated. Eg, for a new, inbound port 80 connection: an upgrade to TLS or h2c would be feasible. During the first request it may transpire that an upgrade to WebSocket is feasible too (authz having been satisfied). Once the request in which the upgrade has been negotiated is complete, said upgrade takes place. Any subsequent requests on the same TCP connection won't be eligible for upgrade to WebSocket. This kind of rule ought to live outside the HTTP/1.x implementation as it has more to do with WebSocket than HTTP. -- Tim Bannister – is...@c8h10n4o2.org.uk
