eworldproblems
  • Home
  • About
  • Awesome Ideas That Somebody Else Already Thought Of
  • Perl defects
  • Books & Resources
Follow

http.sys equivalent for linux – worthy of some thought?



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.

Posted in Uncategorized
SHARE THIS Twitter Facebook Delicious StumbleUpon E-mail
← “I want Porsche Turbo.” malware
SignalR Hub Authorization →

No Comments Yet

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Recent Posts

  • Reset connection rate limit in pfSense
  • Connecting to University of Minnesota VPN with Ubuntu / NetworkManager native client
  • Running nodes against multiple puppetmasters as an upgrade strategy
  • The easiest way to (re)start MySQL replication
  • Keeping up on one’s OpenSSL cipher configurations without being a fulltime sysadmin

Categories

  • Computing tips
    • Big Storage @ Home
    • Linux
  • dev
    • devops
    • Drupal
    • lang
      • HTML
      • JavaScript
      • PHP
    • SignalR
  • Product Reviews
  • Uncategorized

Tags

Apache iframe malware performance Security SignalR YWZmaWQ9MDUyODg=

Archives

  • June 2018
  • January 2018
  • August 2017
  • January 2017
  • December 2016
  • November 2016
  • July 2016
  • February 2016
  • January 2016
  • September 2015
  • March 2015
  • February 2015
  • November 2014
  • August 2014
  • July 2014
  • April 2014
  • February 2014
  • January 2014
  • October 2013
  • August 2013
  • June 2013
  • January 2013
  • December 2012
  • November 2012
  • September 2012
  • August 2012
  • July 2012

Blogroll

  • A Ph.D doing DevOps (and lots else)
  • gavinj.net – interesting dev blog
  • Louwrentius.com – zfs@home with 4x the budget, other goodies
  • Me on github
  • My old edulogon.com blog
  • My old GSOC blog
  • My wife started baking a lot
  • Now it's official, my wife is a foodie

Meta

  • Log in
  • Entries feed
  • Comments feed
  • WordPress.org

EvoLve theme by Theme4Press  •  Powered by WordPress eworldproblems