Breakpoint Debugging
Breakpoint Debugging for HTTP Traffic, Pause requests and responses mid-flight to inspect and edit headers, body, and status code in real time. Pass the modified message or abort the connection.
Breakpoint debugging in HTTPeep works the same way as a code debugger, but for HTTP traffic. You set a breakpoint on a rule or a specific session, and the next time a matching request arrives, HTTPeep pauses it before forwarding it — or pauses the response before delivering it. While paused, you can read and edit any part of the message, then decide whether to pass it on or abort the connection.
Request breakpoints vs response breakpoints
HTTPeep supports two distinct breakpoint types that target different stages of the request lifecycle:
Request breakpoint
Intercepts the request before it is forwarded to the server or resolve outlet. Use this to modify what the server receives — change the URL, swap out a header, or alter the request body.
Response breakpoint
Intercepts the response before it is delivered to the client. Use this to modify what your application sees — change the status code, inject data into the body, or alter response headers.
You can enable both types on the same rule independently.
Setting a breakpoint
Open the rule editor and add a breakpoint action to the Request Actions or Response Actions pipeline. The breakpoint applies to every future request that matches the rule.
requestActions:
- type: breakpoint
id: action_bp_request
enabled: true
responseActions:
- type: breakpoint_response
id: action_bp_response
enabled: trueRight-click any session in the session list and choose Set Request Breakpoint or Set Response Breakpoint. HTTPeep remembers the breakpoint for the duration of the session. This is useful for one-off debugging without creating a permanent rule.
Breakpoints added directly to a session are not persisted to rule.yaml. They exist only while HTTPeep is running and are cleared when you restart.
The editing workflow
When a breakpoint fires, the paused session is highlighted in the session list and an editing panel opens automatically.
Inspect the full request (or response) as HTTPeep received it — headers, body, URL, and method are all visible.
Modify any field directly in the editor:
- Headers — add, remove, or change any header value
- Body — replace or edit the request or response body; the editor supports JSON formatting
- Status code — change the HTTP status code on a response breakpoint (e.g., force a
200to503) - URL — rewrite the request URL before it is forwarded
Choose one of two actions:
- Pass — forward the edited message and continue the request/response cycle normally
- Abort — drop the connection immediately; the client receives a connection error
While a request is paused at a breakpoint, the client waits for a response. Long pauses can cause client-side timeouts. Pass or abort the request promptly to avoid unintended timeout errors in your application.
What you can change
| Field | Request breakpoint | Response breakpoint |
|---|---|---|
| Request headers | Yes | No |
| Request body | Yes | No |
| Request URL | Yes | No |
| Response headers | No | Yes |
| Response body | No | Yes |
| Status code | No | Yes |
Practical use cases
Combine a response breakpoint with a rule that matches a specific path and status code filter. This way the breakpoint only fires on the responses you actually care about — for example, only when a /api/checkout request returns 500.