Peter McGrattan’s Weblog

Silverlight, WCF, ASP.NET, AJAX, Graphics, RIA

Debugging Polling Duplex on localhost with ipv4.fiddler

Posted by petermcg on September 30, 2008

This post takes a brief look at the options for capturing localhost HTTP traffic in the superb Fiddler2 tool but in particular demonstrates how this can be achieved using the less-renowned ipv4.fiddler keyword in a Silverlight 2 polling duplex debugging session.

HTTP traffic sent to or originating from http://localhost or http://127.0.0.1 by Internet Explorer and the .NET Framework is not captured in Fiddler2 by default because the requests and responses do not pass through the WinInet proxy that it registers.  A few simple workarounds do exist to commonly facilitate the capture of this traffic (without customizing Fiddler’s rules) however:

  • Using 127.0.0.1 with a dot suffix
  • Using the Machine Name
  • Using ipv4.fiddler

The rest of this post shows the results of using each of these methods in an attempt to achieve a complete trace of all HTTP traffic being sent and received between my sample Silverlight 2 Beta 2 polling duplex client and server application, the results were quite interesting.  The sample application consists of three projects:

  • The Silverlight 2 Beta 2 client polling duplex application
  • The Web Application hosting the Silverlight client
  • The WCF polling duplex service hosted in a Console Application

The server manually handles the Silverlight client access policy requirements and messages are sent in both directions by both parties.  Capturing all the traffic between the client and server in Fiddler2 requires the base http://localhost url to be manipulated at design time according to the appropriate workaround in each of the three projects.  Let’s take a look at the process using each workaround in turn and the ensuing results:

1. Using 127.0.0.1 with a dot suffix

I first read about this technique here and it does work in a number of more common scenarios, let’s see how it fares in this scenario:

A. Silverlight Client

Firstly the manipulation of the default http://localhost url used to connect to the server duplex service from the Silverlight 2 client project:

// From this
EndpointAddress endPoint = new EndpointAddress("http://localhost:10201/StockService");
// To this - Note the period after localhost
EndpointAddress endPoint = new EndpointAddress(http://127.0.0.1.:10201/StockService);

B. Hosting Web Application

Secondly the same change to the Start URL for the web application that hosts the Silverlight 2 client:

Start Url localhost dot suffix

C. WCF Service Console Application

Lastly a change to the base address of the WCF polling duplex service in the server’s configuration file:

Base address localhost dot suffix

D. Results in Fiddler

Fiddler localhost dot suffix

The screenshot above shows the results of our efforts using this workaround.  The session gets as far as the GET request for the built-in clientaccesspolicy.xml file.  Due to our manually added suffix a HTTP 400 Bad Request – Invalid Hostname response is returned.  This HTTP response is eventually translated into the following exception in the Silverlight client:

Exception localhost dot suffix

2. Using the Machine Name

This is a technique listed in the relevant help section on the Fiddler2 website, lets see what results this workaround yields:

A. Silverlight Client

Again we start with the manipulation of the default http://localhost url used to connect to the server duplex service from the Silverlight 2 client project:

// From this
EndpointAddress endPoint = new EndpointAddress("http://localhost:10201/StockService");
// To this (i.e. Environment.MachineName)
EndpointAddress endPoint = new EndpointAddress(http://vgnar21s:10201/StockService);

B. Hosting Web Application

Again, the same change to the Start URL for the web application that hosts the Silverlight 2 client:

Start Url Machine Name

C. WCF Service Console Application

Lastly a change to the base address of the WCF polling duplex service in the server’s configuration file:

Base address Machine Name

D. Results in Fiddler

Fiddler Machine Name

The screenshot above shows the results of our efforts using this workaround.  The session does not get past the request for the aspx page that hosts the Silverlight application and a HTTP 502 Connection Failed response is returned.  This HTTP response message eventually appears as the following error in Internet Explorer:

IE Machine Name

3. Use ipv4.fiddler keyword

At this stage the two previous workarounds have both proven unsuccessful, let’s try the same process this time with another technique listed in the relevant help section on the Fiddler2 website – use of the ipv4.fiddler keyword.  The ipv4.fiddler keyword requires Fiddler v2.1.8 or later to be running, I should also mention the ipv6.fiddler keyword (not covered in this post) for IPV6 debugging.

A. Silverlight Client

Firstly the manipulation of the default http://localhost url used to connect to the server duplex service in the Silverlight 2 client project:

// From this
EndpointAddress endPoint = new EndpointAddress("http://localhost:10201/StockService");
// To this (Fiddler keyword)
EndpointAddress endPoint = new EndpointAddress(http://ipv4.fiddler:10201/StockService);

B. Hosting Web Application

Secondly the same change to the Start URL for the web application that hosts the Silverlight 2 client:

Start Url ipv4

C. WCF Service Console Application

Lastly a change to the base address of the WCF polling duplex service in the server’s configuration file:

Base address ipv4

D. Results in Fiddler

Fiddler ipv4

Success – this workaround accomplishes exactly what we set out to achieve, the screenshot above shows the capture of all HTTP traffic going between the client and server.  It shows everything from the initial request for the hosting aspx page, downloading the .xap file, the request and custom self-hosted response for the clientaccesspolicy.xml file and finally the actual polling duplex activity on the wire.  Note the content of the User-defined column, this is as a result of turning on ‘Show Time-to-Last-Byte’ and ‘Show Response Timestamp’ under the Rules > Performance menu in Fiddler2.

For a deep-dive into exactly what these polling duplex requests and responses contain, please see the ‘Anatomy of a Bi-Directional Message Exchange’ heading in Part 1 – Architecture of my series of posts on polling duplex in Silverlight 2.

About these ads

4 Responses to “Debugging Polling Duplex on localhost with ipv4.fiddler”

  1. Mazhar Karimi said

    But when it comes the Binary Encoding, fiddler is useless, it doesn’t help much.
    Is there any way to solve it?

  2. Mazhar Karimi said

    Well my problem got solved, as now there is a Fiddler Extention (WCF Binary) available.

  3. […] Debugging Polling Duplex on localhost with ipv4.fiddler – this post is a gem and let’s you see how data is passed between client and server […]

  4. […] that IE9 allows localhost traffic to be intercepted by Fiddler (so no more ipv4.fiddler hacks) […]

Sorry, the comment form is closed at this time.

 
Follow

Get every new post delivered to your Inbox.

%d bloggers like this: