Network Replay Is Protocol Work

Capturing a response body is necessary for network replay. It is not sufficient.

The replay system still needs to know which request the body belongs to, whether request order matters, how headers and credentials are handled, which response type to serve, and when a live external dependency must be refused rather than guessed.

Different protocols expose different contracts.

Request identity is more than a URL

Two requests to the same path can differ by method, query, body, headers, or session context. A matching key may need:

• normalized URL and origin mapping;
• HTTP method;
• request-body fingerprint;
• selected safe headers;
• content and response type;
• GraphQL operation identity;
• captured sequence or ambiguity information.

Fallback matching can improve replay resilience, but ambiguous fallbacks should be suppressed. Serving the wrong successful response is often worse than a visible miss.

Bodies need safe storage semantics

Captured records should distinguish metadata from body bytes. Binary responses must remain binary. Concurrent reads should not mutate shared buffers. Cache lifetime should be scoped and bounded so a long-running replay service does not retain every body forever.

Headers also need sanitation. Hop-by-hop headers, credentials, cookies, and donor-specific transport values should not be copied into a portable local response without policy.

GraphQL has operation authority

GraphQL commonly sends many operations to one endpoint. URL matching alone collapses distinct queries and mutations.

Capture can retain the operation name, query fingerprint, variables shape under redaction policy, and response association. Replay can then select the response that corresponds to the observed operation rather than whichever body shares the endpoint.

This still does not create a GraphQL server. It preserves recorded authority for the captured operations.

WebSockets are ordered conversations

A WebSocket session is not a set of independent responses. Connection establishment, client messages, server messages, timing, and close behavior can all matter.

Replay needs parser-backed callsite or URL transformation, explicit session records, and bounded sequencing. Replacing the browser’s global WebSocket constructor broadly can affect unrelated code and hide unsupported behavior; routing should stay as narrow as possible.

Uncaptured outbound messages or open-ended server behavior should become visible gaps.

HAR is valuable but not magical

An authorized HAR archive can provide request and response evidence without a new live capture. It can also omit WebSocket frames, service-worker behavior, response bodies, or route-local assets depending on how it was created.

The source type and omissions should remain in the capture environment. A later refresh should reuse a HAR only when the workspace records that the original authority came from that archive—not because a similarly named file happens to exist.

Unexpected egress should fail loudly

A local replay can appear successful while continuing to contact the donor or another live service. That weakens portability and can create privacy or safety problems.

Offline verification should block non-loopback traffic and report every attempted external target. Declared retained services can be handled separately, but undeclared egress should not become an invisible fallback.

The honest replay contract

For each network surface, a useful workspace says:

• what was captured;
• how requests are matched;
• which values were redacted;
• which bodies and MIME types are authenticated;
• which ordering assumptions are preserved;
• which misses are ambiguous or unsupported;
• which external authority remains necessary.

KodeCapture treats network replay as protocol reconstruction around recorded evidence—not as a dictionary from URL to body. That distinction is what keeps a local green result connected to the traffic that was actually observed.