Check the response wrapper before replacing the document

A document that opens correctly at its source can fail when delivered through another application. The file may be intact while the receiving response describes its bytes incorrectly. Re-uploading the same document would leave that boundary unchanged.

This fictional investigation follows a product PDF through a website's download proxy. The approved document is D-52. Its source record and contents are not under review; the task is to make the authorised download deliver the same bytes successfully.

Follow both the body and its description

The upstream service sends a gzip-coded representation of D-52 with Content-Encoding: gzip and a length for the coded body. The proxy retrieves it using Python Requests and accesses response.content.

In the inspected path, Requests has already decoded the gzip body. The returned content is the PDF's decoded bytes. The proxy then copies the upstream encoding and length headers into its own response while sending those decoded bytes.

The browser is told to apply gzip decoding to content that is no longer gzip-coded. In this fictional test environment, the download fails during that processing. The original PDF remains readable, and the decoded proxy body has the same hash as the approved source file.

Locate the first inconsistent boundary

The first mismatch is the outgoing response construction. Neither the source document nor the user's permission needs to be changed to explain it.

The official Requests quickstart documents automatic decoding for gzip and deflate content. HTTP semantics defines what Content-Encoding says about the representation. The actual retrieval method matters: another client or a raw streaming interface can expose a different form of the body.

Choose a consistent outgoing representation

The team selects the decoded-body route already used by this application. It stops forwarding the now-inapplicable upstream encoding and length, sets the intended PDF media type and lets the serving framework generate the correct final framing for the outgoing body.

An alternative could preserve the coded bytes and the appropriate metadata together, if supported by the chosen path. Mixing one route's body with the other's headers is the problem. The correction does not disable compression everywhere or instruct every proxy to strip every upstream header.

Other representation-dependent metadata must also be assessed when a body is transformed. The scoped review checks the actual response construction rather than copying a broad list of headers without considering their meaning.

Complete the acceptance trace

The fictional retest retrieves D-52 through the corrected proxy. The saved decoded file matches the approved source hash, opens in the selected reader and shows the expected product reference and document issue. The proxy has not regenerated or edited the PDF.

The upstream is then configured to supply D-52 without gzip coding. The same outgoing path delivers the correct file without trying to decode it again. Independent document D-53 retains its own hash and issue. An unauthorised request still receives the existing denial and no document body.

A source error is also passed through the application's agreed error handling rather than labelled as a successful PDF. This keeps a delivery repair from turning any returned bytes into an apparently approved download.

These are bounded fictional acceptance observations. They do not establish behaviour for every browser, PDF reader or intermediary. A real project needs checks against the actual deployment path, including any additional compression or caching layer.

Preserve the distinction in the handover

Record whether the client returns coded or decoded bytes at the point the application uses them, which layer constructs the final response and how identity is checked. That evidence helps a successor avoid adding another decoding step or restoring the obsolete upstream headers during a refactor.

The product owner still controls D-52's content and approval. The integration repair establishes delivery of the intended bytes; it does not certify the document's technical claims.

Bring the source file, the failed route and the receiving response to an integration assessment. The care service can then scope the smallest supported correction and the controls needed to keep it dependable.