OdeToCode IC Logo

Something to Know about gRPC in ASP.NET Core 3

Tuesday, October 22, 2019

gRPC is a framework you can use in ASP.NET Core 3 to build APIs. The gRPC framework offers both advantages and disadvantages compared to the HTTP based APIs we’ve always been able to build using ASP.NET Core controllers. But, there’s one important aspect of gRPC that is often overlooked in the wave of 3.0 evangelism you read in blogs, hear in podcasts, and see in videos and conferences:

gRPC services won't work in IIS or Azure App Services.

IIS and App Services constitute a non-trivial share of production environments for AspNet Core, so it is regrettable that some developers discover late in the development process that gRPC won’t work for them. Only recently has the documentation for gRPC started to include a warning message:

gRPC warning

What Doesn’t Work?

The warning itself is misleading. IIS and App Services have two different problems.

It’s true that IIS cannot current host a gRPC service because http.sys doesn’t support trailing headers. gRPC relies on trailing headers to communicate vital information, like call status. The first sign of trouble here appears when you scaffold a new gRPC service project using Visual Studio. AspNet Core projects typically include the option to develop using IIS Express, but this launch option is not present after running the gRPC scaffolding.

In Azure, Windows based App Services use IIS and have the same http.sys limitation. However, you can’t circumvent the problem by hosting in a Linux or using a custom container. The App Service front-end terminates incoming TLS connections before forwarding unencrypted messages to your App Service worker. Your gRPC service will refuse to communicate over http and return only HTTP 426 Upgrade Required errors.


There’s currently no timetable I can find for either IIS or App Services to make a workable environment for gRPC services. Fortunately, there are other options for hosting gRPC services in Azure and the cloud including using Kestrel directly in a virtual machine or in a Kubernetes cluster.

The bigger issue for me is the reoccurring problem where Microsoft messaging around new AspNet Core features doesn’t consider the realities of production. Another example of this problem was with the original .NET Core release. While Microsoft was promoting the record performance benchmarks of AspNet Core, all of us hosting AspNet Core on IIS were seeing performance numbers worse than MVC 5. The confusion took a long time to clear up.

Gravatar Adam Stapleton Tuesday, October 22, 2019
See this issue for details: https://github.com/aspnet/AspNetCore/issues/9020
Gravatar pitermard Wednesday, October 23, 2019
thanks for the heads up
Gravatar Gerardo Lijs Wednesday, October 23, 2019
Run into this last week! They confirmed they are working in a Windows Update to fix this, but will probably take some time. Also, if you want to use gRPC APIs from a Framework 4.7.2 it's very difficult to get the SSL certificates to work. Still, tests using gRPC with server and client in netcore3 worked very well for me, so I will definitely try again for real projects once hosting in Azure is possible and by then probably the legacy client will be updated too...
Gravatar Oisin Thursday, October 24, 2019
Funnily enough, it was me who opened the initial github issue and pushed them to add this message after I had wasted a few weeks on prototypes. I've watched the progression over the last two months to go from "oh, we've no idea when Windows will get the neccessary support in http.sys" to "we're working on it, it's hard and we've no timelime." -- it is very surprising that they'd make this such a marquee feature of .net core 3.0 while so many limitations exist.
Your Comment