Skip to content
Mittelware
All posts
how-todebuggingtesting

Pause a request, edit it by hand, then send it

Use a Pause and Review rule to freeze matching requests before they leave your machine, change the method, URL, headers or body, and resume or drop them. A manual breakpoint for the network.

The Mittelware teamUpdated 4 min read

Writing a rule is the right tool when you want the same change every time. Sometimes you want something different: to look at one specific request, tweak a single value, and see what happens. For that there's the Pause and Review action. Think of it as a breakpoint for HTTP.

How it works#

A Pause and Review rule holds matching requests before they're sent. The request waits in the Paused tab on the Flows page. You can then edit it and choose:

  • Resume, to send it on (with your edits, if any).
  • Drop, to discard it so it never reaches the server.

A Pause and Review rule needs no configuration beyond its conditions, which is why it's so quick to set up.

Set one up#

Open Rules, click Create Rule, and fill it in:

  1. Source: the app you're testing.
  2. Label: Review settings writes
  3. When…
    • HTTP Method is PUT
    • URL contains /v1/settings
  4. Then… choose Pause and Review.

Save it, then change a setting in your app. Instead of saving, the app waits. Open the Paused tab and click the request.

To keep the screenshots simple, here is the same kind of rule aimed at a free practice server. It pauses any request for /comments/1:

The Create Rule form: label Review comment requests, a URL contains condition, and the action Pause and Review, with a note that matching requests are held for manual review.
Notice the help text under Then…: nothing else needs configuring. The conditions are the whole rule.

Edit and resume#

Load the page that makes the request. The browser sits there loading, because Mittelware is holding the request. Switch to Flows, open the Paused tab and click the row. The details panel shows who sent it, which rule paused it, and the request itself, with the method and URL ready to edit:

The paused request's Details panel, with the badge Paused by Review comment requests, the URL field now ending in comments/2, and a Drop button and a Resume button with a countdown at the bottom.
1: the URL is an editable field (we changed comments/1 to comments/2). 2: Drop throws the request away, Resume sends it on.

In the paused request you can change:

  • The method
  • The URL
  • Any header
  • The body

Make your change and press Resume. Once resumed, it carries on exactly as if no rule had been involved: the response is whatever the server really sent for your edited version.

Here is what happened to ours. The browser still shows the address it asked for, /comments/1, but the page holds comment number 2:

A browser whose address bar reads jsonplaceholder.typicode.com/comments/1 while the page shows a JSON comment with id 2.
The app asked for comment 1 and was handed comment 2. It has no way to know.

Flows records what was really sent, which is your edited URL, and how long the request sat waiting for you:

The Flows list with one row for comments/2 with a shield icon, status 200 and a duration of 141960 ms, and the Details panel with the badge Review comment requests executed and the comment 2 JSON.
The URL shows the edited address. The duration (about 142 seconds) is mostly time spent paused, while we took screenshots.

What it's good for#

Test server-side validation. Your form won't let you submit a negative quantity or a 10,000-character name, but the API should still reject them. Pause the request and change the body to something the UI would never send.

{ "quantity": -5, "note": "x" }

Check authorization. Change an ID in the URL (/v1/orders/1042 to /v1/orders/1043) or remove the Authorization header and see whether the server really says no. The screenshots above are exactly this trick, with a harmless comment ID.

Flip a flag once. Change a feature flag or role in a single request without reconfiguring anything.

Lose a request. Choose Drop and the request never leaves your machine. It is a quick way to see, once and by hand, how the app copes when a call simply doesn't get through.

Look before it leaves. Sometimes the goal is just to see exactly what is about to be sent, with a chance to stop it. A Pause and Review rule on a destructive endpoint is a cheap safety net while you explore an unfamiliar app.

Things to know#

  • There's a countdown. The Resume button shows how long is left. If you do nothing for five minutes, Mittelware sends the request on exactly as it was when it was paused, so a forgotten pause never leaves things stuck for ever.
  • Clients have timeouts. While a request is paused, the app is waiting on it. Take too long and the client 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.
  • Pause narrowly. A condition like URL contains / will freeze every request the app makes, including the ones it needs to render the page you're trying to test. Match the specific endpoint.
  • Switch it off after. A Pause and Review rule left on is a request left hanging. Use the toggle on the Rules page.

Keep reading