httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <>
Subject Re: Upgrade Summary
Date Fri, 11 Dec 2015 08:56:08 GMT
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.


> Am 10.12.2015 um 23:18 schrieb Jacob Champion <>:
> 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
> 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
> 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
> == 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]

View raw message