I have been a huge fan of Fiddler the HTTP Debugging Proxy for a couple years now. However one thing that always bugged me about any network debugging tool was the fact that it could not debug localhost or 127.0.0.1. However I just found a solution while racking my brain for a way to debug one of my local projects.
I don’t know if many of you are aware but the website http://localhostproxy.com points to 127.0.0.1 as a standard for URL examples.
ping localhostproxy.com
Pinging localhostproxy.com [127.0.0.1] with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128Ping statistics for 127.0.0.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms
So if localhostproxy.com points to the same local IP address as localhost, I figured that I could just use localhostproxy.com instead of localhost in my projects. I used the following setup:
With the above setup I was able to get Fiddler to monitor my localhost traffic my tricking the network card to go external for the localhostproxy.com reference.
So basically that is all that I needed to do and it make pretty quick work of getting around the localhost problem.
Updated: Updated domain to localhostproxy.com instead of somesite.com, because somesite.com was swallowed up by a squatter.
127.0.0.1, Fiddler, How To, localhost, Ping, somesite.com
Check out you lmhost file in c:\windows\system32\drivers\etc – here you can filter specific URL’s to point to another location.
Otherwise you can always use http://{machinename}/default.aspx (or whatever file you are asking for), i.e. http://kbe/default.aspx – this will cause Fiddler to catch up on the HTTP requests even though the files are located on your local IIS.
I think there’s a typo: “one thing that always bugged me about any network debugging tool was the fact that it could debug localhost” should be “that it could NOT debug localhost”.
There are other ways of using Fiddler on a local site:
1) Use your PC’s hostname instead of “localhost”.
2) Edit your Windows hosts file to create additional localhost aliases. See http://blog.kowalczyk.info/kb/local-dns-modifications-on-windows—etc-hosts-equivalent-.html
I understand and know about the hosts and lmhosts file in c:\windows\system32\drivers\etc. And I know about the using your local machine trick too. Also by using your hosts file that is what causes the issue, because the hosts file bypasses the process of sending the request through the normal route, when mapped to 127.0.0.1, which is why localhost doesn’t work. If you removed localhost from the hosts and added localhost to an external DNS you would see localhost to start working in Fiddler.
However my problem is when dealing with a team of developers the easiest solution is usually the best solution. And it is almost impossible to edit your hosts file in Windows Vista because of the protections placed on it, and as outlined above it wouldn’t work anyways. So working on a team where everybody has Vista and different machine names I choose to use http://www.somesite.com.
I probably should have spelled it out, but those are my reasons for choosing something universal such as http://www.somesite.com.
You can also use “localhost.”
“localhost.” has the nasty habit of not working with port numbers at least in my experience.
See any reason to not use your netbios name? eg: http://mycomputername/mysite
I don’t know how reliable it is – AFAIK, only example.* is reserved for examples, but it’s an interesting trick. I wonder who owns somesite.com and why they pointed it to 127.0.0.1…..
Don’t know how long it will be around, but basically it is just a DNS lookup there is no actual site for it. So stability is not an issue.
Created: 2003-07-02
Updated: 2007-06-17
Expires: 2008-07-02
Registrant
SOMESITE.COM
c/o Whois IDentity Shield
142-757 W. Hastings St., Suite #777
Vancouver, BC
Canada V6C 1A1
Administrative Contact
SOMESITE.COM
c/o Whois IDentity Shield
142-757 W. Hastings St., Suite #777
Vancouver, BC
Canada V6C 1A1
E-mail: KbYDlJHYrd5MNdcCS/
Technical Contact
SOMESITE.COM
c/o Whois IDentity Shield
142-757 W. Hastings St., Suite #777
Vancouver, BC
Canada V6C 1A1
E-mail: tInMTdMS88zN3zlv6vN8QAR1e/ZcjWr+jRymBAqH8MsEOT4fJTU=@2008.identityshield.com
Name servers for this domain:
NS1.HITFARM.COM 72.51.27.54
NS2.HITFARM.COM 217.68.70.72
NS3.HITFARM.COM 64.40.116.38
Jeffro,
As stated above when working on teams, you need something that is common in your project configurations. Unfortunately the computer name is… well unique to the computer.
As Nick Berardi Says:
“localhost.” (the dot at the end is important)
It works #1 even with port number “http://localhost.:2128/”
Other workarounds are here: http://www.fiddler2.com/fiddler/help/hookup.asp#Q-LocalTraffic
all kinds of excellentness! Great tip, thanks!