When the Downloaded File Begins with an HTTP Status Line
Keep HTTP response framing out of a downloaded artifact instead of copying every byte received from a proxy socket into the output file.
If a supposed PDF or spreadsheet begins with HTTP/1.1 200 OK, the downloader saved a raw response instead of the artifact. This schematic response contains only four bytes of content:
HTTP/1.1 200 OK
Transfer-Encoding: chunked
4
DATA
0
The artifact is DATA. The status line, headers, size marker and terminating structure belong to HTTP. Removing a fixed number of bytes is unsafe because header lengths vary. Copying everything after the first blank line still leaves chunk framing, and informational replies can precede the final response.
For a normal download, replace the raw-socket-to-file copy with the HTTP client's response-body interface. Configure its proxy, validate the final status and stream the body to a temporary output. The client handles the message framing: length-delimited, chunked and connection-delimited bodies require different parsing.
Content encoding is a further layer. Decide whether you need decoded artifact bytes or explicitly requested raw content using the client's documented behavior. Compressed bytes are not automatically proxy corruption.
If the application must retain socket-level code, it owns all those parsing rules as well as read and write handling. Write only the number of bytes actually returned by a read, not the buffer's capacity, and handle partial writes. Otherwise stale buffer contents can corrupt even a correctly extracted body.
HTTPS needs more than stripping a CONNECT response: after successful tunnel setup, establish destination TLS and then parse the inner HTTP response. The encrypted bytes following the proxy's headers are not the downloadable file.
Leave failed or incomplete output under a temporary name. Publish it only after the transfer and artifact checks succeed; a nonempty file does not demonstrate a complete download.