WCF Posts

• Debugging local traffic with Fiddler: “The Dot Trick”

  

  By Per Lundberg

  Posted in

  

  Code

  Monday, January 11, 2010

  Tags: Webservices , Debugging , HTTP , WCF

  As mentioned in a previous posting, Fiddler can be a great tool when debugging HTTP-based communication, particularly for webservices, WCF and similar (but really, any kind of HTTP traffic can be debugged with the tool). There is just one slight problem with it: by default, it is not usable for debugging localhost-based servers. In other words: if your server URL looks something like http://localhost:12345/MyService.asmx, you will not be able to debug it with Fiddler. That is, unless you apply “The Dot Trick”, which will be described in this blog posting.

  First, let’s discuss the apparent problem and its cause, then we’ll move on to how we can workaround this. Let’s create a scenario: You are having problems with a web request in an application; the web request causes an exception for some reason. More specifically, the request is from a web application (ASP.NET .aspx file) to a web service (.asmx file). Also, you cannot/don’t want to debug this using Visual Studio’s built-in debugger, for one reason or another. This is the error message you’re getting, as presented on the ASP.NET web page:

  

  Now, let’s start Fiddler. This is the output we get:

  

  Switch back to IE, and press F5 to refresh the page (and hopefully reproduce the problem). After doing this, the error appears again in the web page, but… if you now look in the Fiddler window, it looks exactly the same as before you hit F5. How could this be, what on earth is happening?!?

  The answer is this, taken from the Fiddler web page: “Internet Explorer and the .NET Framework are hardcoded not to send requests for Localhost through any proxies, and as a proxy, Fiddler will not receive such traffic” [1] This makes sense if you think about it: a proxy running somewhere in your local network can not fetch data from your local machine, when accessing a localhost-based URL. It could do a best-effort and try to rewrite the url to http://yourmachine:12345 (where yourmachine is the name of your machine), using the IP address provided in the proxy request, but… there’s no guarantee that http://yourmachine:12345 would be the same as your local http://localhost:12345 URL. In fact, when using the Visual Studio built-in web server (a.k.a. Cassini), this would not work at all: Cassini is designed to only listen on localhost traffic!

  Therefore, it is understandable that someone at Microsoft at some point took the decision that WinINET and/or IE/Microsoft.NET  should disregard proxy configurations for localhost-based URL:s.

  So, having stated what the problem is and some theory behind it, let’s move on to the whole point of this blog posting: There is a nifty little workaround to this problem, making it possible to debug traffic to localhost in Fiddler! But only if you have a way to modify the URL, so in some cases it would still be hard/impossible to use this. In our specific use case (an ASP.NET page calling a webservice) though, we can benefit greatly from knowing this. The workaround is what we can call “the Dot Trick”.

  What you simply do is this: change the URL from something like http://localhost:12345/MyService.asmx to be http://localhost.:12345/MyService.asmx. Did you notice the dot? Right after the “localhost” and before the colon a dot (period character) has been inserted. This is what the browser window with the ASP.NET page looks like now (very similar to before, only difference being that the dot has been inserted in the URL):

  

  But now look at our Fiddler buddy! This is what the Fiddler window contains:

  

  Much better, isn’t it? We can now investigate “the red line” and possibly see what was causing this problem. However, that is out of the scope for this blog posting. :-)

  Alright, that’s it for this time. In this blog posting, we’ve learned one of the caveats of Windows HTTP traffic, and how to work around it. I hope the information was useful to some of you; it has sure helped me.

  PS: Rumor has it that “the dot trick” sometimes doesn’t work, e.g. with Windows 7. In that case, you can try http://ipv4.fiddler:12345/MyService.asmx instead. This will be intercepted by Fiddler and converted to localhost:12345, intercepting the traffic as needed.

  0 comments

• Debugging Web Services/WCF Services with Fiddler

  

  By Per Lundberg

  Posted in

  

  Code

  Thursday, November 12, 2009

  Tags: Webservices , Debugging , HTTP , WCF

  As many of you know, a debugger is an invaluable tool for a software developer. A good debugger really helps when tracking down some problem with the software you (or someone else) has written.

  On the other hand, when you don’t have the ability to single-step the code through a debugger, or when you get poor, non-descriptive error messages, it can really be a nuisance. In this blog posting, I will go through the second of these cases (i.e. non-descriptive error messages).

  When working with WCF services, the error messages can sometimes be really unintelligible. Or rather: they don’t tell you very much about the problem. This is the error message I got today when using a WCF service from within a Silverlight 3 application:

  

  Allright. Let’s peek into the View Detail box, shall we? This is what it looked like, after expanding some InnerExceptions:

  

  The stack trace looked like this:

  {System.Net.WebException: The remote server returned an error: NotFound.
     at System.Net.Browser.BrowserHttpWebRequest.InternalEndGetResponse(IAsyncResult asyncResult)
     at System.Net.Browser.BrowserHttpWebRequest.<>c__DisplayClass5.<EndGetResponse>b__4(Object sendState)
     at System.Net.Browser.AsyncHelper.<>c__DisplayClass2.<BeginOnUI>b__0(Object sendState)}
  
  

  Not very descriptive, huh? So, maybe there is a way to get more information about this exception somehow, but… for the sake of this blog posting, let’s assume that it actually is impossible. :-)

  It is my impression that sometimes (for some odd reason…) the real error message is “hidden” within the WCF layer. But, luckily for us, there is an easy way to poke around in the actual communication between the WCF client and the server. Its name is Fiddler, and it’s actually a freeware tool developed by a Microsoft employee. Fiddler works as an HTTP proxy, letting you intercept the traffic between any HTTP client and server (this includes WCF, if you are using one of the http binding types as the binding for your WCF client, which is often the case). When the program is started, it automatically takes over all traffic from most HTTP clients on your client machine (including WCF clients and Internet Explorer). It does so by modifying the the Internet Explorer proxy settings. When Fiddler is closed, it automatically changes the proxy settings back for you, so it’s very convenient to use in that sense.

  Here is what the program looks like when you start it up:

  

  As you see, Fiddler itself has performed an update check to see if any new version of the program is available. If you click this line in the Web Sessions list, you are able to inspect how this specific request/response looked.

  Now, let’s get back to our real-world debugging scenario. We assume that the client has run, and the illegal operation above has been performed. This is what our Fiddler console looks like now.

  

  As you see, even Fiddler itself realizes there something wrong with this request. I guess this is because of the HTTP 500 result code that was sent by the server (HTTP result code 500 means “Internal Server Error”). Let’s click this red-marked row:

  

  We are now shown some basic information about the session, which we are not very interested in right now but which could be more interesting if you were size-optimizing a web site (or just checking how heavy it would be to load over different kind of Internet connections/geographic locations). Let’s open the Inspectors tab (marked with red above).

   

  We are now shown an overview of the HTTP headers involved in this request. Still, we are not getting really what we where aiming for. Let’s open the TextView for both the request and the response (marked with red above).

  

  Now we’re talking! Quite a lot more useful than the “NotFound” error we got earlier. A stack trace is always a lot more useful; as you see, we can even see the line number in the source code file where the error appeared, giving us the opportunity to debug the server and place a breakpoint there (for example).

  Well, that’s basically it. In this blog posting, you have been introduced to a WCF scenario where no real clue was found in the exception details as to what the real problem was. You’ve learned the basic concepts of how Fiddler works, and how you can use it to debug WCF services (and web services, and really any kind of web-related scenario – web browsing, AJAX, you name it…). For those of you who already very skilled in these areas, too bad; you may not have learned very much from this. But relax, take it easy, I’ll write about something more technically challenging some other time. I promise. :-)

  0 comments