Using Fiddler to inspect HTTP traffic

I recently ran into a problem where I was trying to make REST calls to Microsoft’s Azure Notification Hub service to register new devices with a custom template registration. According to the documentation as of 2021/08/17, the following XML is required to create a template registration for Windows devices: 

<?xml version="1.0" encoding="utf-8"?> 
<entry xmlns="http://www.w3.org/2005/Atom"> 
    <content type="application/xml"> 
        <WindowsTemplateRegistrationDescription xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/netservices/2010/10/servicebus/connect"> 
            <Tags>myTag, myOtherTag</Tags> 
            <ChannelUri>{ChannelUri}</ChannelUri> 
            <BodyTemplate><![CDATA[{Template for the body}]]></BodyTemplate> 
            <WnsHeaders> 
                <WnsHeader> 
                    <Header>X-WNS-Type</Header> 
                    <Value>wns/tile</Value> 
                </WnsHeader> 
                <WnsHeader> 
                    <Header>X-WNS-Tag</Header> 
                    <Value>myTag</Value> 
                </WnsHeader> 
            </WnsHeaders> 
        </WindowsTemplateRegistrationDescription> 
    </content> 
</entry> 

When I used this, I got a 200 OK response from the API, but the template did not register. I could confirm this by GETing the registration, where the template was missing in the response. Sending a template notification also did not work.  

However, when using the Azure Notification Hub .NET Nuget package, the registration worked successfully, and I could send notifications using the template. 

After combing through my code, and not finding anything wrong with it, I decided that I needed to see what was different between the API call my code was making according to the documentation, and what the library’s code was doing. To do this, I made use of a free tool (On Windows) – Telerik Fiddler Classic. There is a newer cross-platform solution available, but it is not free. 

After installing Fiddler, you need to set up a proxy so that your HTTP traffic is directed to it. This can easily be done (for .NET Core applications) by opening a command-line window such as Windows Terminal with Administrator Privileges, and entering the following command: 

netsh winhttp set proxy 127.0.0.1:8888 

To remove the proxy again, use the following command: 

netsh winhttp reset proxy 

You need to do this before running the project you want to capture traffic from! 

To inspect HTTPS traffic as well as normal HTTP traffic, you need to go to Tools -> Options -> HTTPS tab and select Capture HTTPS CONNECTs and Decrypt HTTPS traffic. You will have to accept and install Fiddler’s root certificate for this to work. Thereafter, restart Fiddler. 

While Fiddler is running, you can use F12 or File -> Capture Traffic to enable/disable capturing traffic. This can be useful as there may be many requests for other things running on your system. I find it’s easiest to disable capturing traffic and to set a breakpoint on the line of code that will make a network call. Then enable capturing traffic, step over the line, and once the call is made (and logged), disable capturing traffic again. 

Once the traffic is captured, Fiddler will show the request (1) and response (2) on the right-hand side of the application window after you click on a request in the list (3) on the left-hand side. There are various tabs to view only the headers, or the body with specific formatting such as XML or JSON. I normally go with Raw so that I can see everything as it is transmitted. 

This allowed me to see exactly what data was in the request made by the library’s code. As you can see, the XML is slightly different to what was shown on Microsoft’s documentation: 

The XML has a RegistrationDescription element with an i:type of WindowsTemplateRegistrationDescription. In the documentation, RegistrationDescription is WindowsRegistrationDescription without the i:type attribute. When I changed the XML for my direct REST API call to match what the library was doing (and not what the documentation showed), it worked correctly 🎉. 

Leave a comment

Your email address will not be published.