Fiddler user's Manual (iii)------Fiddler command line and HTTP breakpoint debugging

0x00 fiddler built-in commands

In the previous section (using Fiddler for packet Capture analysis), it was introduced in the Web session (not the same concept as what we normally call a session), Every HTTP request here becomes a session) the interface can see all the HTTP requests that the Fiddler crawl. In order to manage all sessions more conveniently, Fiddler provides a series of built-in functions for filtering and manipulating these sessions ( Custom command line operation the children's shoes of Linux should be able to feel how convenient this will be. Enter the location of the command below the Web Session Admin panel (via the shortcut key Alt+q can focus to the command line).

Fiddler built-in commands are as follows: 1. Select command.

Select all of the corresponding types (referred to as Content-type) for the specified type of HTTP request, such as selecting a picture, using the command select Image. While select CSS selects all requests of the corresponding type CSS, select HTML selects all requests that respond to HTML (what about the SQL statement?). ）。 Is the result after the select image is executed:

2. Allbut command.

The Allbut command is used to select all response types that are not HTTP requests of a given type. such as Allbut image is used to select all the corresponding types are not pictures of the session (HTTP request), The command also has an alias keeponly. It should be noted that the keeponly and Allbut commands are deleted from the session that is not of that type, leaving the response of that type. Therefore, if you execute allbut xxxx (a nonexistent type), it is actually similar to executing the CLS command (deleting all sessions, the Ctrl+x shortcut is also this function) 3. ? text command

Select all session 4 for all URLs that match the character after the question mark. >size and <size commands

Select all HTTP request 5 that has a response size greater than a size (in units of B) or less than a certain size. =status command

Select all HTTP requests that have a response status equal to the given state.

For example, select all HTTP requests with a status of 200: =200 6. @host command

Select all HTTP requests that contain the specified HOST. For example: @csdn. Net

Select all host requests that contain csdn.net 7. Bpafter, Bps, BPV, BPM, BPU

These commands are primarily used to set breakpoints in batches

Bpafter XXX: Interrupt URL contains all session responses for specified characters

Bps XXX: Interrupts the HTTP response status for all session responses of the specified character.

BPV XXX: All session responses that interrupt the specified request mode

BPM XXX: Interrupts all session responses for the specified request mode. Equivalent to BPV XXX

Bpu XXX: Similar to bpafter.

When these commands do not have parameters, all HTTP requests that set breakpoints are emptied. 0x01 using fiddler for HTTP Breakpoint debugging

This is one of Fiddler's powerful and practical tools. By setting breakpoints, Fiddler can:

1. Modify the HTTP request header information. For example, the request header of the UA, Cookie, Referer information, through "forge" the corresponding information to achieve the corresponding purpose (debugging, simulation of user real request, etc.).

2. Construct the request data, break through the limits of the form, and submit the data at will. Avoid page JS and form restrictions affecting debugging.

3. Intercept the response data and modify the response entity.

Why is the above method important? Suppose the JS front-end programmer and the server programmer is the division of labor, JS programmers want to debug the function of Ajax requests, so that the server-side programmers do not have to wait for the development of all interfaces before the development of the JS side of the AJAX request function, because through the "simulation" of the real server-side response, can guarantee the correctness of the function, and the server-side development programmer, as long as the final response is guaranteed to comply with the provisions. This greatly simplifies the efficiency of program development and, of course, reduces the difficulty of linking programmers to different lines of business.

There are two ways of setting breakpoints:

1.fiddler menu bar->rules->automatic breakpoints-> Select a breakpoint, in this way the breakpoint set will be valid for all subsequent HTTP requests.

There are two breakpoint locations:

A. Before response. That is, after the request is sent, but before the Fiddler agent Relays, the requested data can be modified.

B.after Response. That is, after the server responds, but before fiddler the response to the client. You can then modify the result of the response.

2. Enter the command line. Bpafter xxx or BPV,BPU,BPM, etc. set breakpoints. This breakpoint is only for a specific type of request.

As an example of a local Web project, we demonstrate how to set HTTP breakpoints simply:

1. First set up the Firefox agent, so that it can crawl all HTTP requests (localhost request, you can also set in the filter only crawl intranet request), set as shown:

2. Then open the local project with the Web. The content of the page is:

4. Set the post-response breakpoint (after response breakpoint), which can be set via the command line: Bpafter localhost. After you type enter, the Web accesses the file again, and through the Fiddler Web session interface, you can see that the request has been hung up, and the Web browser has been loaded. Looking at the right side of the Inspector panel, there is something new:

In this case, we can modify the response information. The modification process is:

Switch to the TextView sub-panel, select the section you want to modify, and then click "Run to complete" to echo the modified response. Suppose we revise the following:

After clicking on Execute, open the Web interface just now. Can see the changes of the page.

Visible, the response of the page has changed accordingly. This is the post-response breakpoint. Of course, in practical applications, breakpoints are more complex to set and respond to than this, and here is just a basic example.

The ways to terminate breakpoints are:

1. Clicking "Run Complete" on the Inspector interface terminates the breakpoint for this HTTP request.

2. Entering the GO command also causes the current request to skip the breakpoint.

3. Disabled breakpoints in Rules->auto breakpoint.

In short, Fiddler's breakpoint function is very powerful, about its further study and application, need a continuous accumulation and groping process.

Original: http://blog.csdn.net/ohmygirl/article/details/17855031

(EXT) Fiddler user's Manual (iii)------Fiddler command line and HTTP breakpoint debugging