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 suffixI 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 ClientFirstly 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 ApplicationRead more: Peter McGrattan’s Weblog
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 suffixI 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 ClientFirstly 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 ApplicationRead more: Peter McGrattan’s Weblog
0 comments:
Post a Comment