Reading the Upload in Chunks Doesn't Require Chunked HTTP
Separate bounded application reads from HTTP/1.1 message framing when an upload behaves differently through a forward proxy.
No. A client can read a large file in small buffers and send it with a known Content-Length. Bounded reads control memory use; HTTP framing tells the recipient where the request body ends.
A stable file whose byte length the HTTP library knows is different from a generator producing an unknown amount of data. Use the library's supported body interface for either source. You do not need to assemble the entire file into a string just to provide a length.
For HTTP/1.1, inspect the framing actually sent: Content-Length or chunked transfer coding under the protocol's rules. Chunked coding adds size markers outside the file content. Do not combine contradictory framing fields or guess a length to persuade a proxy to accept the upload.
If a proxied upload fails, record the HTTP version, body source and first rejection. A 411 response suggests a different investigation from a connection closing halfway through a body. If authentication retries fail instead, check whether the upload body can be replayed. Changing the application's read-buffer size may leave the request framing exactly as it was.
The route matters to that observation. Plaintext forwarding exposes the upload's HTTP framing to the proxy; ordinary end-to-end HTTPS puts it inside a tunnel. HTTP/2 uses its own framing. Historical Squid limitations therefore explain particular old failures, not a rule that every current proxy rejects streamed uploads.