Ever since I learned of Microsoft’s kernel-mode HTTP listener, http.sys, I’ve for the first time personally felt that Microsoft has done something in the HTTP server arena that Linux can’t currently shake a stick at. (If you’re unfamiliar with http.sys, it basically is the first thing on Windows servers to touch incoming http requests, and parses their headers just enough to determine what resource is being requested before delegating the rest of the request handling to a user-mode processes that has been designated to handle the requested URL.) I’ve found http.sys to be quite useful with development in windows-land: when your windows application needs to receive commands over the network, you have a very straightforward and interoperable option: expose a SOAP web service right on port 80, with the internal web service implementation residing in-process as part of your program. (.net’s WCF is also a key element here to handle the low-level network security and stuff.) Again: on Windows, your custom application can expose HTTP web services on port 80/443, right beside IIS and any other processes on that server & IP address that accept HTTP requests.
Linux, on the other hand, just doesn’t do this. Mapping of incoming traffic to OS processes strictly follows the traditional OSI level 4 examination of the port, and so the maximum number of processes you can have registered with the kernel to listen to HTTP requests on port 80 is 1. Apache is awesome and all, but it aint always everything for everybody.
Sure, there are workarounds that could be concocted on Linux to achieve similar behavior to what I described above if your goal was only to do the business-level processing of an http request inside some process other than Apache. A simplistic approach would be to write a php script that interacted with “your” process via a named pipe. You could probably even write an apache module that handed off the TCP socket handles etc. for lower-level control of the request processing within another process (or maybe not, I’m no expert w/apache mods.) But for a couple reasons, I don’t feel schemes like this are as good as what you can do on Windows.
First, any such scheme is dependent on the presence of a properly installed, configured, and maintained user-mode HTTP server installation on the machine in addition to the process you actually want to have handling the request. Linux server administrators would have to pick an http server software to use on their servers, and then hope that any applications they may want to run in future support request handoffs from the http server they chose. With Windows, server administrators don’t even need to have IIS set up on the machine to download and run a custom program that exposes its own web services - they just know it’ll work out of the box. Adding an HTTP request parser/delegator to mainline Linux would fix this by providing a de-facto API for all software to be written against.
Another potentially huge use of an http.sys equivalent for Linux that comes to mind (though it may become less relevant if IPv6 ever becomes truly universal) would be to securely cram more www sites onto a single IPv4 address. Think of the possibilities: hosting companies could contain each site on a shared server in its own apache installation, each running with its own permissions, and potentially tracked separately by AppArmor. One client’s Drupal installation is a year out of date and got exploited? No problem, the HTTP requests used to exploit it were mapped to a process that only had access to that client’s files, so the damage was contained to the guy that didn’t update his site. The closest equivalent I’m aware of currently is hypervisor-based virtual machines (VPS’s), which still need separate IP addresses for each VPS if all sites are to remain on :80.
So, I would be very interested to hear a well thought out discussion by Linux networking and kernel gurus as to whether this is something that they too think would be beneficial to the Linux environment.