The bug I'm reporting is sometimes the Session.HostnameIs() will return true even if the supplied hostname does not match Session.hostname and a port was passed by the client in the Host header.

HostnameIs function is documented as "This method compares the supplied hostname to the hostname of the request, returning true if a case-insensitive match is found."

What I think is happening is that rather than use Session.hostname for comparison Fiddler instead uses the Session.host (ie what was passed by the client in the Host header) and if a port is present maybe it incorrectly extracts out the hostname. Here is an example that shows the bug and why I think that.

In OnBeforeRequest add this code, which should only show an alert box if the hostname is test:

		if(oSession.HostnameIs("test")) {
			FiddlerObject.alert(oSession.hostname);
		}

Now in a browser try going to http://t:81/ and you will see it shows the alert box, in other words a match. Why? Well, I will guess based on my testing that your code in HostnameIs gets the index of the colon in the host t:81, which is 1, and then compares only that number of characters. So it's doing whatever is the javascript equivalent of !strnicmp("t", "test", 1).

This manifests itself through CONNECT as well, and probably more likely, since the standard ports are used in the Host header (IE might be an exception to this). For example, let's say you go to https://t/ in Firefox or Chrome and HTTPS decrypt is enabled. The Host passed by the client for the CONNECT is t:443 and so it's the same problem, !strnicmp("t", "test", 1).

This is not a theoretical issue for me, I was testing something earlier today where I had to treat a hostname that ended in .co different from the same hostname that ended in .com and it turned out the test I was doing applied to both of them because of this bug.