What happened?

When a pass-through endpoint proxies a request to an upstream API that returns a gzip-compressed response, the client receives a Content-Length header that does not match the actual response body size, causing connection errors.

This is because get_response_headers() in pass_through_endpoints.py strips content-encoding but does not strip content-length. Since httpx auto-decompresses the gzip response, the forwarded content-length reflects the compressed size while the actual body sent to the client is the decompressed (smaller) size.

Root Cause

In pass_through_endpoints.py line 321:

excluded_headers = {"transfer-encoding", "content-encoding"}

The flow:

1. LiteLLM's internal httpx client requests the upstream with Accept-Encoding: gzip (httpx default)
2. Upstream returns gzip-compressed body (e.g. 58 bytes) with Content-Length: 58 and Content-Encoding: gzip
3. httpx auto-decompresses the body to 34 bytes, but response.headers["content-length"] still reads 58
4. get_response_headers() strips content-encoding: gzip but keeps content-length: 58
5. FastAPI sends 34 bytes of body with Content-Length: 58 header to the client
6. Client reads 34 bytes, expects 24 more, connection closes → error

Steps to Reproduce

1. Configure a pass-through endpoint to any upstream that returns gzip-compressed responses (e.g. BytePlus Ark API):

general_settings:
  pass_through_endpoints:
    - path: /pass/bytepluses
      target: https://ark.ap-southeast.bytepluses.com/api/v3
      headers:
        Authorization: Bearer <API_KEY>
        content-type: application/json
      include_subpath: true

1. Make a request through the proxy:

curl --http1.1 -v -X POST http://localhost:4000/pass/bytepluses/contents/generations/tasks \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <LITELLM_KEY>" \
  -d '{"model":"dreamina-seedance-2-0-260128","content":[{"type":"text","text":"a cat walking"}],"ratio":"16:9","duration":5,"watermark":false}'

1. Observe the response headers show mismatched Content-Length:

< Content-Length: 58        ← compressed size from upstream
{ [34 bytes data]           ← actual decompressed body
* transfer closed with 24 bytes remaining to read

Error Messages

• HTTP/1.1: curl: (18) transfer closed with 24 bytes remaining to read
• HTTP/2: curl: (92) HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)
• Python httpx: httpcore.RemoteProtocolError: peer closed connection without sending complete message body (incomplete chunked read)

Proposed Fix

Add "content-length" to excluded_headers:

excluded_headers = {"transfer-encoding", "content-encoding", "content-length"}

FastAPI's Response(content=bytes) automatically calculates the correct Content-Length from the actual body. This is safe for all cases:

• Gzip responses: Fixes the mismatch (compressed size → correct decompressed size)
• Non-gzip responses: FastAPI calculates the same value as upstream, no behavior change
• Streaming responses: StreamingResponse does not use Content-Length

Related Issues

This is the response-direction counterpart of #10010, which reported the same class of Content-Length mismatch bug in the request direction for Bedrock pass-through.

Relevant log output

Content-Length: 58
actual body: {"id":"cgt-20260413154202-bd945"} (34 bytes)
mismatch: 58 - 34 = 24 bytes (matches curl error exactly)

What LiteLLM version are you on?

v1.82.0-stable.patch5 (ghcr.io/berriai/litellm-database:main-v1.82.0-stable.patch5)

Are you a ML Ops Team?

No