Why is it inherently 'madness' to have part of your HTTP stack running in kernel space? I think it's generally accepted that handling TCP in the kernel isn't madness; what's the magic distinction between dealing with TCP packets from remote machines and dealing with HTTP requests from remote machines that makes one of them an acceptable activity to carry out in kernel space, and one not?

To be clear about http.sys, it's not what you would normally consider a 'web server'. It leaves things like 'serving files' and 'authentication' and stuff up to userland application processes like IIS. But it allows multiple userland applications to be routed HTTP requests directly, without an IPC dispatch.

It's the amount of complexity, i.e. the number of things to go wrong.

Handling TCP/IP in the kernel requires substantially less complexity than handling HTTP/TCP/IP.

And even then, there are efforts (GNU Hurd, for instance) to push things like TCP out of the kernel level.

> I had no idea. Madness

They aren't the only ones who do this: https://www.freebsd.org/cgi/man.cgi?accf_http . All sorts of things are kernel-accelerated on modern operating systems, including lots of network operations. From that perspective, this is just one more and it could potentially have a huge benefit (like the same page served count on fewer hardware) for customers who need it.

Obviously it's critically important that MS get this right if they're going to offer it at all, but that's pretty much a tautology when talking about kernels and core OS functionality. Judge them on a bad implementation, not on any inherent badness in the idea.

You haven't read the manpage, have you?

The idea is completely different.

accf_http is... here, just read the source: https://github.com/freebsd/freebsd/blob/master/sys/netinet/a... – if it sees something that looks like an HTTP request and delays returning to userspace until \r\n\r\n.

http.sys is an actual HTTP/1.x parser. That runs in ring 0.