Learn how to use Fiddler Everywhere when calling a gRPC service from a .NET Core client both as a RESTful service over HTTP/1 and natively over HTTP/2.
I suspect that I can still debug Web service applications without using Fiddler Everywhere … but I wouldn’t want to have to find out. Fiddler Everywhere continues to see improvements in both functionality and ease-of-use. The current version, for example, includes support for gRPC services, including both “native” gRPC mode over HTTP/2 and “transcoded” mode over HTTP/1.
I’ve looked at creating a gRPC service with transcoding support using Visual Studio with .NET Core elsewhere. This post is about how you can use Fiddler Everywhere when calling a gRPC service from a .NET Core client over HTTP/1 and HTTP/2.
HTTP/2 support for using Fiddler Everywhere with gRPC is automatically enabled for all users. If you want to check this, first start Fiddler Everywhere (from here on, I’ll just call it “Fiddler”). After starting Fiddler, click on the Settings icon in the upper right corner of the Fiddler window and, when the Settings dialog appears, click on the Connections tab on the left and make sure the Enable HTTP/2 Support option is checked.
By the way: If this is the first time you’ve started Fiddler, stop and take a moment to a) look Fiddler’s UI showing all the traffic entering and leaving your computer and b) be amazed by the sheer amount of traffic that’s entering and leaving your computer.
Now you’re ready to write your code to work with Fiddler and with gRPC transcoding on HTTP/1. You’ll need to adjust your default gRPC HTTP/2 code to work with Fiddler and your default RESTful HTTP/1 code to work with a transcoded gRPC service.
If you’re not using Fiddler Everywhere, you would typically use code like the following to create a GrpcChannel object. After creating your channel object, you then pass that channel object to your gRPC client as part of creating the client (the client class’s code will have been generated for you from your gRPC’s service .proto file). That code would normally look something like this:
GrpcChannel gChan = GrpcChannel.ForAddress("https://<URL for gRPC Service>")
GreeterClient gc = new MyGrpcClient(gChan);
Once Fiddler starts, it sets up a proxy that all your network traffic will go through and then reports on that traffic. You’ll need to tweak your gRPC code to play nicely with Fiddler’s proxy which just means adding the extra code shown here to set some GrpcChannelOptions when creating your channel object:
GrpcChannel gChan = GrpcChannel.ForAddress("https://<URL for gRPC Service>",
new GrpcChannelOptions
{
HttpHandler = new HttpClientHandler()
});
GreeterClient gc = new MyGrpcClient(gChan);
With your gRPC code now compatible with Fiddler, you can tweak your RESTful code to work with a gRPC service in transcode HTTP/1 mode. In the past, when calling a RESTful/HTTP 1 service you’ve probably written code like this in .NET Core. This code uses the standard .NET HttpClient object to retrieve an HttpResponseMessage from a RESTful, HTTP/1 service:
HttpClient hc = new HttpClient();
HttpResponseMessage hrpm = await hc.GetAsync("http://<URL> for RESTful HTTP 1 Service>");
While that code is great for a native HTTP 1 service, you need slightly different code to work with a gRPC service that’s using JSON transcoding to make itself available over HTTP/1. To have your .NET Core work with your transcoded gRPC service, you’ll need to add some code when creating your HttpClient object to specify the version of the request message sent to the service by your HttpClient object. That code looks like this:
HttpClient hc = new HttpClient() {
DefaultRequestVersion = new Version(2, 0)
};
HttpResponseMessage hrpm = await hc.GetAsync("https://<URL> for gRPC Service");
With those three changes, you’ll be positioned to have your .NET Core project to work both with Fiddler Everywhere and with a gRPC service in all of its manifestations.
Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter also writes courses and teaches for Learning Tree International.