Pause and Review
Hold a matching request before it leaves your computer, read it, edit its method, URL, headers or body by hand, then resume it or drop it. A breakpoint for HTTP.
A rule is the right tool when you want the same change every time. Pause and Review is for the other case: you want to look at one particular request, change a value, and see what happens. It holds a matching request before it is sent, so you can inspect and edit it, then decide whether it goes on. Think of it as a breakpoint for HTTP.
Use it to:
- Look before it leaves. See exactly what is about to be sent, with a chance to stop it. A cheap safety net while you explore an unfamiliar app, or around a destructive endpoint.
- Test server-side validation. Your form won't let you submit a negative quantity, but the API should still reject it. Pause the request and edit the body.
- Check authorization. Change an ID in the URL, or remove the
Authorizationheader, and see whether the server really says no. - Flip something once. Change a feature flag or a role in a single request, without reconfiguring anything.
- Lose a request. Drop it, and see how your app copes when a call doesn't get through.
NOTE
Pause and Review is only available when all of a rule's conditions look at the request, because it holds the request before it's sent.
Set it up#
Choose Pause and Review under Then…. There's nothing else to configure: the conditions are the whole rule.
Keep the conditions narrow. A condition like URL contains / would freeze every request the app makes, including the ones it needs to draw the screen you're trying to test. Match the one endpoint you care about, such as URL contains /v1/settings together with HTTP Method is PUT.
Review a paused request#
With the rule on, trigger the request in your app. The app waits, because Mittelware is holding the request. Open Flows, switch to the Paused tab and click the row.
The details panel shows who sent the request, which rule paused it, and the request itself, ready to edit. In this picture, (1) is the URL field, which we changed from comments/1 to comments/2, and (2) holds the two buttons that decide what happens next.
You can change:
- the method
- the URL
- any header
- the body
Resume or drop#
| Button | What happens |
|---|---|
| Resume | The request is sent on with your edits. The response is whatever the server really sent for the edited version, as if no rule had been involved |
| Drop | The request is thrown away and never reaches the server. Your app is answered with a 403 Forbidden and no body, so it sees a refusal and not silence |
After a resume, the flow moves out of the Paused tab and shows up under Intercepted, with the rule's badge, as any request a rule acted on.
The countdown#
The Resume button shows a countdown. If you do nothing for five minutes, Mittelware sends the request on exactly as it was when it was paused, with none of your unsent edits, so a forgotten pause never leaves your app stuck for ever.
Things to know#
- Clients have timeouts. While a request is paused, the app is waiting on it. Take too long and the app may give up, so the answer you resume has nobody left to receive it. Work quickly, or raise the timeout in the app you're testing.
- Switch it off afterwards. A Pause rule left on is a request left hanging every time it matches. Use the switch on the Rules page.
- You'll see the edited request in Flows. The URL column shows what was really sent, which is your edited address, and the duration includes the time you spent deciding.
- For the same edit every time, write a Modify Request rule instead.
Worked example#
Pause a request, edit it by hand, then send it walks through a full example with screenshots.