Features to Retarget Requests
1. Use the HOSTS… command on the Tools menu to reroute traffic from one IP address to another
…loading https://example.com/ will show a certificate warning complaining that the server presented a certificate for www.fiddler2.com instead of the expected example.com certificate:
You can avoid the Certificate Error message by setting the X-IgnoreCertCNMismatch flag:
if (oSession.HTTPMethodIs("CONNECT") &&
oSession.HostnameIs("example.com")) {
oSession["X-OverrideHost"] ="www.fiddler2.com";
// Set flag to suppress Fiddler's HTTPS Name Mismatch errors oSession["X-IgnoreCertCNMismatch"] = "no worries mate";
}
If you would prefer that Fiddler ignore all certificate errors for a Session, because the target site is using an expired or self-signed test certificate, set the X-IgnoreCertErrors flag instead.
The Host Remapping tool sets the X-IgnoreCertCNMismatch flag automatically. When the Certificate Name Mismatch error is ignored, you will see the https://www.fiddler2.com/ page while the browser’s address bar shows https://example.com/.
Method #3 - Redirecting
A redirect occurs when you use Fiddler to return a HTTP/307 redirection response to the client so that it will resend its request using a new URL. Because the client is responsible for resending the request, it is aware that the request target has changed, and the new request will be sent with an updated Host header and URL. The client will send the proper cookies for the target URL, and if the request is over HTTPS, the client will expect the target server to use the correct certificate for the new target URL. Since the new request is sent with the new target URL and matching Host header, the request will safely flow through an upstream gateway proxy to the desired server.
Features to Retarget Requests
Fiddler allows use of any of these three basic techniques via several independent features:
1. Use the HOSTS… command on the Tools menu to reroute traffic from one IP address to another.
62 | Techniques and Concepts
2. Using FiddlerScript or an extension, you can set the X-OverrideHost flag on the Session object to reroute traffic from one IP address to another.
3. Using FiddlerScript or an extension, you can set the Session object’s host property or fullUrl property to rewrite a request from one URL to another.
4. You can use the utilCreateResponseAndBypassServer method from FiddlerScript or an extension to gen-erate a redirect from one URL to another.
5. You can also use the AutoResponder to rewrite a request from one URL to another by supplying the new URL as the Action text.
6. You can use the AutoResponder to redirect a request from one URL to another using the *redir: prefix on the Action text.
7. You can use the AutoResponder to reroute a request from one host to another by using
*flag:X-OverrideHost=targethost as the Action text.
63 | Techniques and Concepts
C O M P A R I N G S E S S I O N S
One of the most common debugging tasks is to determine why one request was successful while another failed in some way. The ability to compare one Session to another is a powerful tool for accomplishing this task.
To compare two Sessions, simply select both in the Web Sessions list and choose Compare from the context menu (or hit CTRL+W). When you invoke the comparison command, the two selected Sessions will be saved to temporary files and then the file comparison tool will be launched and passed the path to the two files.
Fiddler does not itself install a file comparison tool, although most developers already have WinDiff, Odd, Beyond Compare, WinMerge or a similar utility installed. If you have WinDiff, copy it to the \Program Files\Fiddler2 folder, or put it somewhere within your system's PATH (e.g. C:\Windows\System32) in order for Fiddler to find it. If you don’t already have a comparison tool, grab WinMerge from http://WinMerge.org.
To instruct that Fiddler should launch a tool other than WinDiff, you need to set three Preferences using the QuickExec box or the about:config tab. First, provide the path to the tool:
PREFS SET fiddler.config.path.differ "C:\Program Files (x86) \Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe"
Then, configure the command line arguments to match what the tool expects:
PREFS SET fiddler.differ.Params "/diff \"{0}\" \"{1}\""
You can also set an "alternate" command line that will be invoked if you hold SHIFT while invoking the comparison:
PREFS SET fiddler.differ.ParamsAlt "/diff \"{0}\" \"{1}\""
The alternate command-line feature works with file comparison utilities that support multiple modes. For example, WinDiff offers the -p command line flag to break each line of the comparison at the first instance of punctuation.
64 | Techniques and Concepts
When you hold SHIFT while clicking the “Compare” option, Fiddler will pass the -p flag to WinDiff and a new line will appear after each character of punctuation. This is useful to observe deltas within long lines of text (e.g. a URL’s query string).
UltraDiff
By default, Fiddler reformats the temporary files for easier viewing in line-based comparison tools like WinDiff.
Called UltraDiff, this feature reorders the headers of both files such that headers that are exactly the same in both Sessions are listed first, then headers with different values are listed, then headers that are entirely different are listed last. UltraDiff reformats request URLs to ensure that if the URLs are only slightly different (e.g. a single character differs in the middle of a 512-character URL) then that difference is made obvious.
You can set the fiddler.differ.ultradiff preference to false if you don't want Fiddler to modify the headers and URL when saving the temporary files.
Comparing Multiple Sessions at Once
If you want to compare multiple sessions (or even entire SAZ files) at one time, you should use the Traffic Differ extension, described in the Extensions chapter. That extension allows you to compare lists of Web Sessions and then perform text-comparisons of individual sessions within those lists.
65 | Techniques and Concepts
D E B U G G I N G W I T H B R E A K P O I N T S
In a traditional debugger, you can select instructions in your program at which you would like execution to pause;
these are called breakpoints. While paused at a breakpoint, you can examine the state of the program and modify memory or the flow of execution to change the behavior of the program.
Fiddler offers similar breakpoint-based debugging functionality for web requests. Sessions may be paused at two points during their execution:
1. After the request is read from the client, before it’s sent to the server
2. After the response is received from the server, before it’s returned to the client These are known as request breakpoints and response breakpoints.
When paused at a request breakpoint, you can change any aspect of the request, including the URL, headers, or body.
You may prevent the request from being sent to the server at all, returning a response of your choosing. With rare exceptions, the client application will never know that Fiddler has modified its request.
Similarly, when paused at a response breakpoint, you can change any aspect of the response, including the headers or body. You may also generate a new response and substitute it in place of the response received from the server. At a response breakpoint, you can change any aspect of the request, but since the request has already been sent, the change is only reflected in Fiddler—the server will never see your changes.
Setting Breakpoints
There are many different ways to set breakpoints; under the covers, all of them set the Session’s X-BreakRequest or X-BreakResponse flag.
You can easily break on all requests or responses using the Rules > Automatic Breakpoints menu, or by clicking into the 3rd panel from the left on Fiddler’s status bar. The problem with setting such broad breakpoints is that you will likely find it tedious to unpause each request that you are not interested in debugging.
Instead, consider using the Filters or AutoResponder tabs to more precisely target your breakpoints. The Filters tab allows you to set breakpoints on Sessions that use the POST method, those sent with a Query String, those sent by XMLHttpRequest, or those that returned a particular Content-Type. The AutoResponder tab allows you to set a request or response breakpoint for any request whose URL matches the text or regular expression you provide. Set the rule’s Action text to *bpu to create a request breakpoint, or *bpafter to create a response breakpoint.
If you need to define more elaborate breakpoint conditions, use Rules > Customize Rules to set the X-BreakRequest or X-BreakResponse flags within your FiddlerScript’s OnBeforeRequest, OnPeekAtResponseHeaders, or
OnBeforeResponse methods.
66 | Techniques and Concepts
The default FiddlerScript file allows you to easily set a single request breakpoint and a single response breakpoint using the QuickExec box. Simply type:
bpu TextFromURL
…to set a request breakpoint for any session whose URL contains the specified text. Similarly, type:
bpafter TextFromURL
…to set a response breakpoint for any session whose URL contains the specified text.
You can also set a request breakpoint for any request using a specified HTTP Method:
bpm POST
… and you can set a response breakpoint for any response returning a specified HTTP Status code:
bps 307
Typing any of the breakpoint commands (bpu, bpafter, bpm or bps) with no parameter following will clear the specified breakpoint.
Recompiling your FiddlerScript (or restarting Fiddler) will also clear breakpoints set using QuickExec.
Tampering Using Inspectors
When paused at a breakpoint, you can use Inspectors to edit the request or response. As discussed in the Inspectors chapter, many Inspectors support Read/Write functionality that you can use to change the request and response headers or body. Changes you make while paused at a breakpoint are committed automatically by the Inspector.
In addition to using the Inspectors, you can clone a previously-captured response into a Session paused at a break-point. The Clone Response command is available from the context menu when two Sessions are selected in the Web Sessions list and one of the Sessions is currently paused at a breakpoint and the other is completed. The command will copy the response from the completed Session to the paused Session. This feature enables you to easily replicate a previously captured (or modified) response to satisfy a later request.
The Breakpoint Bar
A red Breakpoint Bar will appear between the Request and Response Inspectors when a Session is paused. This bar includes two buttons and one dropdown.
67 | Techniques and Concepts The yellow Break on Response button is enabled only when paused at a request breakpoint. When pressed, it will set a response breakpoint for the current Session and then unpause its execution, sending the (potentially modified) request to the server. The green Run to Completion button will unpause the request and allow it to run freely without breaking on the response.
The dropdown at the right side of the Breakpoint Bar allows you to select a template response or the file of your choosing to return as the response to a request.
When you select a file from the dropdown, it will be immediately loaded into the response Inspectors so that you may further modify the response (without changing the file on disk) before it is returned to the client. If you use the dropdown to select a response while paused at a request breakpoint, the request will never be sent to the server, because Fiddler will provide the response.
Resuming Multiple Sessions
If your breakpoints are not targeted specifically enough, you may have many requests paused at breakpoints that you wish to resume quickly.
Simply click the Resume button on the Fiddler toolbar, or type g in the QuickExec box to immediately resume all paused Sessions.