[Http] fiddler (III)-Fiddler command line and HTTP breakpoint debugging

1. built-in fiddler commands.

In the previous section (using fiddler for packet capture analysis), we introduced that in the web session (unlike the session we usually call, each HTTP request here becomes a session) you can see all HTTP requests captured by Fiddler. to facilitate the management of all sessions, Fiddler provides a series of built-in functions for filtering and operating these sessions. (It is convenient to use command lines to operate Linux ). enter the command at the bottom of the web session management Panel (you can use the shortcut key Alt + Q to focus on the command line ).

The built-in commands of Fiddler include the following:

1. SELECT command.

Select All HTTP requests of the specified type (Content-Type). For example, select image by running the select image command. select CSS allows you to select all requests with the corresponding type of CSS, and select HTML Selects all requests with the response as HTML (how is it similar to SQL statements ?). Is the result after the select image is executed:

2. allbut command.

The allbut command is used to select all HTTP requests whose response type is not the given type. For example, allbut image is used to select all sessions (HTTP requests) for which the corresponding type is not an image. This command also has an alias keeponly. note that the keeponly and allbut commands will not delete sessions of this type, leaving all the responses of this type. Because of this, if you execute allbut xxxx (the type does not exist), it is similar to executing the CLS command (delete all sessions, CTRL + X is also used to delete all sessions)

3 .? Text command

Select all sessions where all URLs match the characters after question marks

4.> size and <SIZE command

Select All HTTP requests whose response size is greater than a certain size (unit: B) or smaller than a certain size

5. = STATUS Command

Select All HTTP requests whose response status is equal to the given status.

For example, select all HTTP requests in the 200 status: = 200

6. @ host command

Select All HTTP requests that contain the specified host. Example: @ csdn.net

Select all requests whose hosts contain csdn.net

7. bpafter, BPS, BPV, BPM, BPU

These commands are mainly used to set breakpoints in batches.

Bpafter XXX: indicates the response of all sessions whose URLs contain specified characters.

Bps xxx: interrupts all session responses in the HTTP response status of a specified character.

Bpv xxx: interrupts all session responses in the specified request Method

Bpm xxx: interrupts all session responses in the specified request method. Equivalent to BPV xxx

Bpu xxx: similar to bpafter.

When no parameters are added to these commands, all HTTP requests with breakpoint settings are cleared.

For more commands, refer to the Manual on the official website of Fiddler.

 

2. Use fiddler for HTTP breakpoint debugging.

This is another powerful and practical tool for Fiddler. By setting breakpoints, Fiddler can:

1. Modify the HTTP request header information. For example, you can modify the UA, cookie, and referer information in the request header and use the "forged" information to achieve the desired purpose (debugging, simulating real user requests, etc ).

2. Construct request data, break through form restrictions, and submit 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? Assume that JavaScript front-end programmers and server programmers work in a division of labor. js programmers want to debug the Ajax request function, in this way, you do not have to wait for the server programmer to develop all the interfaces before developing the JS-side Ajax request function. By simulating the real server-side response, you can ensure the correctness of the function, as long as the server development programmer ensures that the final response should comply with the regulations. This greatly simplifies the program development efficiency and, of course, reduces the difficulty of joint debugging by programmers in different business lines.

There are two ways to set breakpoints:

1. From the fiddler menu bar-> rules-> automatic breakpoints-> select the breakpoint method. The breakpoint set in this mode will be valid for all subsequent HTTP requests.

There are two breakpoint locations:

A. Before response. That is, after a request is sent, the request data can be modified before the fiddler proxy passes through.

B. After response. That is, after the server responds, but before fiddler forwards the response to the client. You can modify the response result.

2. Enter the command line. Bpafter xxx or BPV, BPU, BPM, etc. This type of breakpoint only applies to specific types of requests.

The following uses a local web project as an example to demonstrate how to set an HTTP breakpoint:

1. First set the Firefox proxy to capture all HTTP requests (localhost requests can also be set in the filter to only capture Intranet requests), as shown in:

 

2. Open the local project on the web. The page content is:

 

4. Set the breakpoint after the response (after response breakpoint). You can set it through the command line: bpafter localhost. After you press enter, the Web will access the file again. You can see through the fiddler web session interface that the request has been mounted and the web browser has been loading. Observe the Inspector panel on the right. Something new also appears:

 

Then we can modify the response information. The modification process is as follows:

Switch to the textview subpanel, select the part to be modified, and click "run to complete" to return the modified response. Assume that the modified content is as follows:

 

Click execute to open the Web interface. Page changes.

 

It can be seen that the page response has changed accordingly. This is the post-response breakpoint. Of course, in actual application, the breakpoint settings and the modification of the response will be much more complicated than this. Here is just a basic example.

You can terminate a breakpoint:

1. Click "run complete" on the inspector interface to terminate the HTTP request breakpoint.

2. Enter the go command to skip the breakpoint of the current request.

3. In rules-> auto breakpoint, disable the breakpoint.

In short, the breakpoint function of Fiddler is very powerful. further learning and application of Fiddler requires a process of continuous accumulation and exploration.

[Http] fiddler (III)-Fiddler command line and HTTP breakpoint debugging