A web server gets big, complicated, has lots of add-on parts, and has performance constraints. Small routers, DNS servers, and BGP servers are small, closed systems that should Just Work. You want to get them working, lock the code into read-only memory, and forget them.
If you are reading RFC2616 closely enough then you'll see that you don't really need to implement anything more complicated than what is in 1.0. E.g it technically requires you to support Keep-Alive, but it also states that the server is allowed to close the connection anytime it wants.
What counts as a web server is quite a bit more complex, esp implementation. Even lighthttpd is non-trivial. The standards are for the tiniest core of the problem while leaving off significant issues. That might be acceptable in a web interface to trusted computer as Im advocating. It's barely a web server, though.
A web server has no utility by itself, it only gains value by running content on top of it. This is where simple becomes too simple in almost every case. A DNS server however can basically start being useful as soon as it is connected to the internet.
> I'll add a web server, Redox or UNIX compatible, that's efficient enough to be deployed in all these web-enabled embedded devices.
I took that to mean something capable of being used as a web admin console for the other services. HTTP/1.0 is fully capable of that. I agree that HTTP/1.0 would be a bit anemic for those that want to support an actual site, but as a simple included way to provide an admin interface, it should be sufficient.
That was the intent and solution I had in mind. Appreciate the positive feedback as I might do it myself given all the ridiculously tiny web servers people have made.
My favorite trick I saw was one that replied directly with TCP/IP packets pre-encoded from the HTML. Cool, huh? That could even be done with highly assured tools in safer language as part of CMS or web build system.
Kbenson gets what Im saying with a simple, static server for interfaces and such. I totally agree that a more feature-rich server, esp tolerant of hostile networks, has all kinds of performance and structuring issues that arent easy to do. Got to learn tat the hard way applying B3 class assurance to one I built. The FSM's and info flows piled up quicker than most would think.
