Summary

During large file transfers (ZIP/PDF/TXT), the response may be truncated while still returning HTTP 200 OK, leaving consumers unaware that the payload is incomplete.

Technical Constraint

With chunked transfer encoding, the status line is sent as soon as streaming begins; the status cannot be changed to 413 mid-stream.

Proposed Approach

• The backend can optionally include the Content-Length header.
• If Content-Length is present and exceeds valid.max.message.size.in.bytes, the gateway short-circuits and returns 413 Payload Too Large (no body is streamed).
• If Content-Length is present and ≤ the limit, the response is passed through unchanged.
• If Content-Length is absent, the current behavior remains (streaming with possible truncation).

Acceptance Criteria

• If Content-Length > valid.max.message.size.in.bytes → gateway returns 413 with no body.
• If Content-Length ≤ limit → response is forwarded as-is (status and body unchanged).
• If Content-Length is absent → no change to current behavior (streaming, potential truncation).

Steps to Reproduce (example)

1. Proxy a backend response that streams a large file and omits Content-Length.
2. Configure valid.max.message.size.in.bytes to a value smaller than the file size.
3. Observe that the gateway returns 200 OK while truncating the body.

Request

Implement a response-path check based on the optional Content-Length header and handle 413 according to the rules above.