Jacob, thanks for the code! I will let this and my pseudo code stew over the weekend and then probably next week start the changes to upgrade handling.
//Stefan > Am 10.12.2015 um 23:18 schrieb Jacob Champion <champio...@gmail.com>: > > Okay, I finally have actual code to share. This is the original experimental > pre_protocol_switch hook that Stefan and I were talking about a while ago > [1], rebased onto 2.4.18. The two patches are available at > > https://github.com/jchampio/httpd/commits/dev/websocket-protocols > > It is *not* an implementation of Stefan's most recent pseudocode (a primary > difference is that his proposal does the filter + upgrade in one hook instead > of two), and it doesn't solve many of the use cases that you've already > agreed must be handled: > > - 100-continue is not handled correctly > - the incoming request body is not correctly dealt with > - there is only one switch point, at the handler stage > - etc. > > *But* it is a working implementation from mod_websocket's point of view, so I > offer it up primarily for informational purposes. The module making use of > the new hook is available at > > https://github.com/jchampio/apache-websocket/blob/dev/hook/mod_websocket.c > > You might be most interested in the mod_websocket_pre_protocol_switch() > implementation (line 1627), which contains the pre-upgrade checks I need to > do to remain compliant with RFC 6455. > > == Asides == > > 1) The current Protocols API does not correctly ignore upgrades from HTTP/1.0 > requests; the latest commit to my experimental branch patched this. > > 2) As Stefan and I discussed in [1], Upgrade header values are case-sensitive > (correct?), but the RFC 6455 declares that servers should respond to any > protocol that's a case-insensitive match for "websocket". To make matters > worse, the official IANA upgrade token is "WebSocket", but the RFC uses > "websocket" throughout. I have seen both used in the wild (Autobahn uses > WebSocket; Firefox uses websocket), and I'm not sure what the right way to > resolve this is. > > Hope this helps. Again, I don't expect this to actually be part of the final > solution, but sometimes it's nice to see code. > > --Jacob > > [1] > https://mail-archives.apache.org/mod_mbox/httpd-dev/201509.mbox/%3c55ff85f0.8040...@gmail.com%3E
