Reconstruct a request from the supplied network.har to investigate it outside the original browser interaction. Review the destination, credentials, and side effects before executing it.

Extract the request

1. Open network.har in a trusted HAR viewer or editor.
2. Find the entry by method, URL, absolute time, subject identifier, or payload value.
3. Inspect its URL, headers, cookies, query values, and postData before constructing a command in your HTTP tool.
4. Remove or replace expired credentials and change the destination to an authorized test environment.

Some HAR tools can generate cURL, but inspect their output before execution. Preserve the captured body format rather than rewriting it into a more familiar shape.

Inspect a request from the sample files

In the sample investigation, log.entries[4] is the POST that moves the card to In progress. Its method, URL, headers, and serialized postData.text describe the captured request.

The body wraps id and status in an application-specific encoding. Replacing it with a plain { "id": "…", "status": "in_progress" } object would change the wire format. Use the target application’s client or the correct serialized body for its current build. The captured /_serverFn/ route may also change between builds.

Start with the read-only comparison: the POST sends no blocked field and the subsequent GET retains the blocked value. Replay only if it will answer a remaining question, using your own test card and environment. The sample’s creation body is redacted, so it cannot supply complete setup.

Prepare a safe reproduction

Read the URL, method, headers, and body. Change the destination to an appropriate test environment if necessary. Supply approved test credentials for redacted or expired values. Check cookies and anti-forgery tokens rather than assuming they remain valid.

A replayed request can create, update, or delete data. Confirm the operation and use disposable test records where needed. Do not execute copied commands blindly.

Compare the response

Run the reviewed request with your HTTP tooling and compare status, response content, and timing with the recorded evidence. Record which inputs or headers you changed.

A cURL request does not reproduce the browser’s DOM state or browser-enforced cross-origin behavior. A success outside the browser may therefore narrow the investigation without resolving the original failure.

Handle incomplete evidence

Missing or truncated bodies cannot be recovered by copying the request. Streaming messages and WebSocket frames are not equivalent to an ordinary request replay. If required context is absent, capture a new focused attempt with suitable rules.

Share the result, original evidence reference, and changed conditions with the investigator. Keep credentials out of the issue and shared command text.