Using Conditions and Actions
A rule in Fiddler Everywhere is a feature that enables you to use a condition to match targeted traffic (HTTP requests and responses) and then apply a specific action to modify its original behavior.
The article lists and explains the supported matching conditions and applicable actions while creating a rule with the Rules tab in Fiddler Everywhere. It also covers the specifics of final and non-final actions and their immediate result on the modified traffic.
Conditions
The Rule Builder can add and use single or multiple matching conditions needed to trigger different actions. The conditions are logical structures with different statements whose numbers can vary between two and four. A statement field that handles text (string modifier) is case-insensitive by default (you can use the Aa button to change them to case-sensitive) and can be auto-completed with suggestions corresponding to the captured sessions.
For more information, refer to the following list.
| Condition Value | Field Options | Field Options | Field Options | Usage Description |
|---|---|---|---|---|
| All Sessions | n/a | n/a | n/a | Matches all captured sessions |
| URL | String modifiers | Search value | n/a | Matches a specific keyword in the URL column. |
| Host | String modifiers | Search value | n/a | Matches a specific keyword in the Host column. |
| Path | String modifiers | Search value | n/a | Matches a specific keyword in the path column. |
| Protocol | HTTP, WebSocket, Socket.IO, RPC, gRPC, SSE | n/a | n/a | Differentiate the traffic based on the used protocol |
| Method | String modifiers | Search value | n/a | Matches sessions using specific HTTP Method. |
| Status Code | String modifiers | Search value | n/a | Matches a specific keyword in the Result column. |
| HTTP Version | String modifiers | Search value | n/a | Matches a specific HTTP Version. |
| Request Header | Header name | String modifiers | The search value | Matches sessions with specific keyword in the explicitly mentioned Request header column. |
| Response Header | Header name | String modifiers | The search value | Matches sessions with specific keyword in the explicitly mentioned Response header column. |
| Request Body | String modifiers | Search value | n/a | Matches sessions with specific keyword in the Request Body column. |
| Response Body | String modifiers | Search value | n/a | Matches sessions with specific keyword in the Response body. |
| Request Cookie | Cookie name | String modifiers | Search value | Matches sessions with specific keyword in the explicitly mentioned Request Cookie. |
| Response Cookie | Cookie name | String modifiers | Search value | Matches sessions with specific keyword in the explicitly mentioned Response Cookie. |
| Request Body Size | Number modifiers (compares bytes) | Search value | n/a | Matches session with specific Request Body Size. |
| Response Body Size | Number modifiers (compares bytes) | Search value | n/a | Matches session with specific Response Body Size. |
| Request Time | String modifiers | Search value | n/a | Matches specific date string in the Request Time column. |
| Request Date | Date modifiers | Date form | n/a | Matches session executed on a specific date. |
| Duration | Number modifiers (compares milliseconds) | Search value | n/a | Matches sessions with specific Duration. |
| Client IP | String modifiers | Search value | n/a | Matches session with specific Client IP. |
| Remote IP | String modifiers | Search value | n/a | Matches session with specific Remote IP. |
| Certificate Information | Field name | String modifiers | Search value | Matches HTTP responses with specific keyword in the explicitly mentioned certificate field. |
| TLS Version | String modifiers | Search value | n/a | Matches traffic based on the used TLS Version. |
| Process | String modifiers | Search value | n/a | Matches a specific Process ID. |
| Comment | String modifiers | Search value | n/a | Matches sessions with specific Comment column. |
| Rules Modified | Boolean | n/a | n/a | Matches sessions modified by a rule. |
| Magic String | The "magic string" content | n/a | n/a | Uses the legacy Fiddler Classic string literals and regular expressions. |
Actions
When Fiddler Everywhere identifies a request that matches the rule's conditions, it automatically maps it to the action set in the rule. An action field that handles text (string modifier) is case-insensitive by default (you can use the Aa button to change them to case-sensitive) and can be auto-completed with suggestions corresponding to the captured sessions. Note that multiple actions will be executed in their numbered order, and action with the final action type will prevent the execution of all subsequent actions. All actions in Fiddler Everywhere can be dragged and dropped to change their execution priority and each action can be quickly duplicated or deleted (thorugh dedicated buttons).
Apart from returning files or predefined responses, a rule in Fiddler Everywhere can perform the following specific actions:
| Action name | Field Options | Field Options | Preview box | Usage Description | Action type |
|---|---|---|---|---|---|
| Mark Session | Choose background color | Choose foreground color | Sample Preview box | Marks the session with selected colors. | Non-final |
| Update URL | Value modifiers | New value | n/a | Uses the selected value modifier and the new value to update the current URL. Does not work for CONNECT requests | Non-final |
| Update Query String | Query Parameter Key | Value modifiers | New value | Uses the selected value modifier and the new value to update the query parameters. | Non-final |
| Update Status Code | n/a | n/a | n/a | Modifies the status code returned by the server while preserving the other data untouched. | Non-final |
| Update Request Header | Header Name | Value modifiers | New value | Uses the selected value modifier and the new value to update the request header. | Non-final |
| Update Response Header | Header Name | Value modifiers | New value | Uses the selected value modifier and the new value to update the response header. | Non-final |
| Update Request Body | Value modifiers | New value | n/a | Uses the selected value modifier and the new value to update the request body. | Non-final |
| Update Response Body | Value modifiers | New value | n/a | Uses the selected value modifier and the new value to update the response body. | Non-final |
| Update Request Cookies | Cookie Key | Value modifiers | New value | Uses the selected value modifier and the new value to update the cookie value. | Non-final |
| Update Response Cookies | Cookie Key | Value modifiers | New value | Uses the selected value modifier and the new value to update the cookie value. | Non-final |
| Set Request Breakpoint | Before Sending a Request> | n/a | n/a | Pauses the session before the sending request from Fiddler to the targeted server. The action works only for newly established connections. | Non-final. |
| Set Response Breakpoint | Before Sending a Request | n/a | n/a | Pauses the session before the sending the response from Fiddler to the client application. The action works only for newly established connections. | Non-final. |
| Return File | File Picker | n/a | n/a | Returns the picked response file. | Final |
| Return Manual Response | Text field for creating manual response | n/a | n/a | Returns the manually created response. | Final |
| Return Predefined Response | Predefined responses | n/a | n/a | Returns the selected predefined response. | Final |
| Return CONNECT Tunnel | n/a | n/a | n/a | This action should be used when you wish to test a URL, which will not be resolved by your DNS Server. The option is also reffered as "Accept all CONNECTs". This action is incompatible with sessions snapshots (saved traffic). | Final |
| Do Not Show | n/a | n/a | n/a | Hides the matched session for appearing in Fiddler. When the Do Not Show action is applied, no other actions will be executed. | Final |
| Do Not Decrypt | n/a | n/a | n/a | Skips decryption for a matched session and shows only CONNECT tunnels. Compatible with the following conditions: All Sessions, URL, Host, Scheme, Client IP, Process. The action works only for newly established connections. | Final |
| Close Gracefully | n/a | n/a | n/a | This action will close the connection gracefully. | Final |
| Close Non Gracefully | n/a | n/a | n/a | This action will close the connection forcefully. | Final |
| Delay Request | Number value (milliseconds) | n/a | n/a | Delays the request execution with "n" milliseconds. | Non-final |
| Comment | String modifiers | New value | n/a | Action to modify, add, or remove a session comment | Non-final |
| Magic String | The "magic string" content | n/a | n/a | Uses the legacy Fiddler Classic string literals and regular expressions. | Non-final |
Final and Non-Final Actions
Rule actions can be divided into final and non-final depending on their behavior and whether their presence will allow our actions and rules to be executed. By default, some actions are already final (refer to the detailed actions comparison table above). However, each non-final action can be explicitly made final through the dedicated checkbox "Stop processing more rules" while creating the action in the rules builder.
When you work with final and non-final actions, take into consideration the following insights:
- Final actions prevent the execution of any other actions in the same rule.
- Final actions prevent the execution of any other rule with lower priority (placed lower in the Rules list).
- Final actions are valid (as final) only when the rule matches an HTTP(S) session.
- If a session matches with conditions that depend on its response (for example, a response body contains "HTML"), then any final action in any rule that matches the session will be ignored. The reason for this behavior is that final actions replace the response. By design, Fiddler is not intended to replace a response that was already received and matched conditions in a rule.
- Non-final actions are non-blocking - they will allow actions from any other active rules to execute.
- A non-final action can be explicitly made final by checking the "Make this action final" option.
The following table demonstrate what happens when you combine final and non-final actions in one or multiple rules.
| Actions Type | Result |
|---|---|
| Only non-final actions | All matching rules have their actions performed and applied |
| Only final actions | When a final action triggers, the execution of the rule immediately stops. No other demoted actions or rules will be executed after that. For example, Do Not Show and Do Not Decrypt are final actions. |
| Mix of final and non-final Actions | When a final action triggers, the execution of the rule immediately stops. No other demoted actions or rules will be executed after that (but promoted actions & rules won't be blocked). |
When mixing non-final and final actions, note that their behavior also varies depending on the moment of execution. For example, assume you have a promoted non-final rule A based on a response matching condition. Then, we also have a demoted final rule B based on a request matching condition. The executing logic will be as follows:
- During the request phase, Fiddler skips the non-final rule A (no match), executes the final rule B, and then stops executing further actions.
- During the response phase, Fiddler will execute non-final rule A (as it now matches). Since rule B is final and was already executed, Fiddler will stop executing further actions & rules.
As a result, the session will bear the action from non-final rule A, even though the final rule B was with lower priority. This is because the final action only blocks the execution of further actions and rules but does not block the execution of actions and rules that come before it.
Matching Conditions Specifics
When creating a matching condition in Fiddler Everywhere, you should consider the following:
- Fiddler Everywhere will try to match each session before a request is sent to the server (Fiddler receives requests > match > Fiddler forwards the request to the server) and before a response is sent to the client (Fiddler receives response > match > Fiddler forwards the response to the client app)
- Match conditions will be tested when all the information is available. For example, match conditions that only require data available for the requests are tested before the request is sent to the server. On the contrary, match conditions that depend on a value from the response are tested before returning the response.
- All rules and their matching conditions are tested in order of appearance from top to bottom.
- If a rule contains a matching condition related to a response but contains actions related to the request, then the specific action will be executed after the server receives the request, and all changes will be visible in Fiddler Everywhere only. The user receives a warning within the UI about the above behavior.
- Each rule's matching conditions are tested on the applied changes from the previous rule's executed actions.
Actions and Rules Execution Specifics
Multiple rules enable you to create complex logic that mocks, modifies, and tests your upcoming and outgoing traffic. Sometimes, you will also need to create a combination of the above actions. This section highlights some specifics you must consider while executing multiple rules and actions.
- Each rule will execute independently.
- No rules can block the execution of other rules.
- All actions in this rule will be executed once a rule matches (through the set matching conditions).
An example of the above statement: A rule with matching conditions on the HTTP request and actions on the HTTP response will match before sending the request, and the actions will be applied before returning the response.
- All actions in a rule are executed in the order of appearance, from top to bottom. Actions can be dragged and dropped to change their execution priority.
- If a final action executes, the rules' processing on these sessions stops immediately. Fiddler won't process and perform any other rules or actions (even in the same rule).
- If a rule's actions are incorrectly ordered and a response action is before a request action, the request action will be executed after the server receives the request. The changes will be visible in Fiddler only.
- Actions placed after a final action in one rule will not be executed.
- The Return File, Return Manual Response and Return Predefined Response actions do not execute any connection to the server, they immediately set the HTTP response to the specified value.
- If you execute multiple rules that modify the same thing in the session, the Fiddler will execute both rules in the order they have been set and change the state of the session with each rule action.
- If you execute rules based on the results of other rules, Fiddler will execute only the first rule. The second, third, etc., will not be executed because the condition they use to test the session has changed, and there will be no match.
Rules Order
Note that each rule is prioritized in the Rules list and can be demoted and promoted, which will change the execution order. Final rules won't block other active rules that have higher priority the Rules list.
For an illustration of this scenario, refer to the following cases:
- You have a rule with a final action (for example, the Close Gracefully final action).
In this case, the rule containing the final action has higher priority in the Rules list. When the matching request is made, only the first rule will execute, and other demoted rules (and actions) will not be triggered.
- You have a rule with non-final action (for example, the Mark Session action).
In this case, the rule containing the non-final action has higher priority in the Rules list. When the matching request is made, the non-final action will execute, and then the following demoted rule will be triggered as well. If you add additional rules after the rule that contains final actions, they won't be executed.
