WebSocket servers on Windows Server
This is a slight continuation of the previous WebSockets versus REST… fight! post.
Buoyed with enthusiasm of WebSockets, I set about implementing a simple test harness of a WebSockets server in C#.NET using
System.Net.HttpListener. Unfortunately, things did not go well. It turns out that
HttpListener (and indeed, the underlying HTTP Server API a.k.a.
http.sys) cannot be used at all to develop a WebSockets server on current versions of Windows. The
http.sys is simply too strict with its policing of what it believes to be correct HTTP protocol.
In an IETF discussion thread, a Microsoft fellow called Stefen Shackow was quoted as saying the following:
The current technical issue for our stack is that the low-level Windows HTTP driver that handles incoming HTTP request (http.sys) does not recognize the current websockets format as having a valid entity body. As you have noted, the lack of a content length header means that http.sys does not make the nonce bytes in the entity available to any upstack callers. That’s part of the work we will need to do to build websockets support into http.sys. Basically we need to tweak http.sys to recognize what is really a non-HTTP request, as an HTTP request.
Implementation-wise this boils down to how strictly a server-side HTTP listener interprets incoming requests as HTTP. For example a server stack that instead treats port 80 as a TCP/IP socket as opposed to an HTTP endpoint can readily do whatever it wants with the websockets initiation request.
For our server-side HTTP stack we do plan to make the necessary changes to support websockets since we want IIS and ASP.NET to handle websockets workloads in the future. We have folks keeping an eye on the websockets spec as it progresses and we do plan to make whatever changes are necessary in the future.
This is a damn shame. As it stands right now, Server 2008/R2 boxes cannot host WebSockets. At least, not whilst sharing ports 80 and 443 with IIS web server. Because, sure, you could always write your WebSocket server to bind to those ports with a raw TCP socket and rewrite a ton of boilerplate HTTP code that
http.sys can already do, and then put up with the fact that you can’t share the port with IIS on the same box. This is something that most people, me included, do not want to do.
Obviously it isn’t really anyone’s fault because back in the development time frame of Windows 7 and Server 2008/R2 (between 2006 to 2009) they could not have foreseen the WebSockets standard and the impact it might have on the design of APIs for HTTP servers.
The good thing is that Windows 8 Developer Preview seems to have this covered. According to the MSDN documentation, the HTTP Server API’s
HttpSendHttpResponse function supports a new special flag called
HTTP_SEND_RESPONSE_FLAG_OPAQUE that seems to suggest it will put the HTTP session into a sort of “dumb mode” whereby you can pass-thru pretty much whatever you want and
http.sys won’t interfere:
Specifies that the request/response is not HTTP compliant and all subsequent bytes should be treated as entity-body. Applications specify this flag when it is accepting a Web Socket upgrade request and informing HTTP.sys to treat the connection data as opaque data.
This flag is only allowed when the
101, switching protocols.
ERROR_INVALID_PARAMETERfor all other HTTP response types if this flag is used.
Windows Developer Preview and later: This flag is supported.
Aside from the new
System.Net.WebSockets namespace in .NET 4.5, there are also clear indications of this behaviour being exposed in the
HttpListener of .NET 4.5 through a new
HttpListenerContext.AcceptWebSocketAsync() method. The preliminary documentation seems to suggest that this method will support 2008 R2 and Windows 7. But this is almost certainly a misprint because I have inspected these areas of the .NET 4.5 libraries using Reflector and it is very clear that this is not the case:
HttpListenerContext.AcceptWebSocketAsync() method directly calls into
System.Net.WebSockets.WebSocketHelper (static class) which has a corresponding
AcceptWebSocketAsync() method of its own. This method will then call a sanity check method tellingly named
EnsureHttpSysSupportsWebSockets() which evaluates an expression containing the words “
ComNetOS.IsWin8orLater“. I need say no more.
It seems clear now that Microsoft has chosen not to back port this minor HTTP Server API improvement to Server 2008 R2 / Windows 7. So now we must all hope that Windows Server 8 runs a beta program in tandem with the Windows 8 client, and launches within a month of each other. Otherwise Metro app development possibilities are going to be severely limited whilst we all wait for the Windows Server product to host our WebSocket server applications! Even still, it’s a shame that Server 2008 R2 won’t ever be able to host WebSockets.
It will be interesting if Willie Tarreau (of HA-Proxy fame) will come up with some enhancements in his project that might benefit those determined enough to still want to host (albeit, raw TCP-based) WebSockets on Server 2008 R2.