nuxx.net Posts

When troubleshooting issues with proxy auto-config (PAC) files and WinHTTP on Windows 8.1 you may wish to view the cached PAC files which the WinHTTP Web Proxy Auto-Discovery Service have written to disk. These cached PAC files can be found in c:\Windows\ServiceProfiles\LocalService\winhttp and are named with a nine digit number and a cache extension (eg: 1667635681.cache). There is also a cachev3.dat file which appears to contain the download location of the PAC file, the MIME type of the file, and the download date/time.

This can be discovered by using Process Monitor with a filter of Path contains winhttp when the WinHTTP Web Proxy Auto-Discovery Service is started (net start WinHttpAutoProxySvc).

Beware: The use of Fiddler to troubleshoot Internet Explorer issues can complicate the use of the Local intranet zone by effectively disabling the intended behavior of the Include all sites that bypass the proxy server setting. KB174360 describes the Local intranet zone as follows:

By default, the Local Intranet zone contains all network connections that were established by using a Universal Naming Convention (UNC) path, and Web sites that bypass the proxy server or have names that do not include periods (for example, http://local), as long as they are not assigned to either the Restricted Sites or Trusted Sites zone.

When Fiddler is enabled, proxy settings on a client machine are changed to direct all traffic to 127.0.0.1 as seen above. This results in no websites automatically matching the Local intranet zone because none bypass the proxy server.

While troubleshooting a suspected issue with custom user agent entries I had Fiddler running, as is my normal practice.  The reported issues was custom user agent strings not being sent, something that won’t happen on IE9 unless Compatibility View is enabled. I’d first thought there was a problem with the Display intranet sites in Compatibility View option not working due to the Local intranet zone assignment not working, but my issue actually turned out to be Fiddler getting in the way by causing no sites to match the Local intranet zone. When Fiddler was disabled and I switched to using an external tap for monitoring, behavior returned to normal.

Fiddler is great for MITMing secure sessions thus making troubleshooting secure websites trivial, so not being able to use it in these circumstances will cause other problems. But there are other ways around that…

I recently had an issue where an application which supports proxies but doesn’t prompt for credentials needed to use a proxy server to communicate with the internet. The solution? Use Fiddler and its built in scripting language as a secondary proxy chained to the primary, forcibly sending a valid authentication header to the proxies.

How does one this? Here’s how, which is a bit more detailed writeup than what’s found here at Stack Overflow. Note that this presumes basic familiarity with Fiddler:

1. Use Fiddler to watch a session that uses Basic authentication to the proxy. Look at one of the requests headers after successful authentication and find the line which contains Proxy-Authorization: Basic. Copy this value to the clipboard. (Example line: Proxy-Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQxMg==)
2. In Fiddler, click Rules → Customize Rules to open CustomRules.js in an editor.
3. Locate the function OnBeforeRequst. The line beginning this will read something like static function OnBeforeRequest(oSession: Session) and is line 159 in the rulset that ships with Fiddler v4.4.9.2 (latest as of November 6, 2014).
4. Below this, add a line as follows, with the secondary part being the string that was copied in step 1. In this example the bolded portion is what we’ve added:
   [...]
static function OnBeforeRequest(oSession: Session) {
// Inject a Basic authentication header
oSession.oRequest["Proxy-Authorization"] = "Basic Yno5eWw1Oldyb25nLmdvLldheSsyNDA=";
// Sample noRule: Color ASPX requests in RED
// if (oSession.uriContains(".aspx")) { oSession["ui-color"] = "red"; }
[...]
5. Save and close CustomRules.js. Fiddler will now begin using this modified ruleset. You can observe that this header is now included with every request.
6. Ensure that your application using Fiddler as its proxy. If the application is local to the computer on which Fiddler is running and uses WinINET then this is likely automatic. If not, it will need to be manually pointed to the local proxy. Fiddler can also accept connections from computers elsewhere on a network (Tools → Fiddler Options… → Connections), but configuration of this is beyond the scope of this article. See the Fiddler documentation for more information.