Really illustrates the dumbassery of sticking a (relatively) fast-moving application-layer protocol into the kernel. Now you can't update the Web Server without updating the operating system.
Might have been handy to beat benchmarks back in the day when people liked to whip them out for comparison, but IIS is under 10% according to Netcraft now. Time to fold up the tent and go home.
I suppose .Net Core is sticking with Http.sys to avoid implementing their own web server, but is tying yourself to the Windows shipping cycle worth it ?
The default ASP.NET Core server is Kestrel which runs in-process and is cross platform. Kestrel has officially supported gRPC for over a year now[1]. That linked GitHub comment is specifically about IIS gRPC support which relies on HTTP.sys (which runs in kernel mode and is tied to the Windows shipping cycle as noted).
> Really illustrates the dumbassery of sticking a (relatively) fast-moving application-layer protocol into the kernel.
Really? There are lots of problems with doing HTTP in the kernel, but “fast moving” is a new one. HTTP was stuck in permafrost from 1995 to 2015. If it weren’t for Google, neither of HTTP 2 or 3 would have ever happened.
They’ve already folded up shop and solved these problems with Kestrel.
Them continuing to offer support for laggards using IIS shouldn’t be criticised though.
Might have been handy to beat benchmarks back in the day when people liked to whip them out for comparison, but IIS is under 10% according to Netcraft now. Time to fold up the tent and go home.
I suppose .Net Core is sticking with Http.sys to avoid implementing their own web server, but is tying yourself to the Windows shipping cycle worth it ?