KB Article #176289

Error seen in external system when API Gateway does not send content-length header

Problem

-- The API Gateway does not send a content-length header and this omission causes an error with an external system, such as a proxy or ICAP provider.

Resolution


* When there is no content-length header, this indicates that the API Gateway is attempting to communicate with the other system using CTE (chunked transfer encoding), which is a feature in HTTP/1.1 that transmits data in 'chunks.' When using CTE, each chunk has its own length and the messages must not contain a content-length header. Certain older systems, such versions of Nginx prior to version 1.3.9, do not understand the encoding and fail with error messages indicating that content-length header is missing.


The ideal solution is to upgrade the other system to a version that understands CTE, enabling you to gain the performance benefits of HTTP/1.1. As a fallback option, you may be able to work around some faults by ensuring that if you have a 'remote host' within Policy Studio, you have it set to connect to the legacy system using HTTP/1.0 and tell it to include the Content-Length when possible. This isn't always reasonable with larger requests, because the gateway would have to buffer the entire message to calculate the length and the next hop may very well time out before the message can be forwarded. It is sometimes possible to use an 'HTTP Parser' filter to avoid streaming and make sure a message is fully buffered before starting to forward it, but this imposes serious performance penalties on the API Gateway to support the legacy behavior of the other server. You can expect higher memory usage and increased latency if you try this route.

Note that every HTTP/1.1 complaint system is required to understand CTE per RFC 2616, section 3.6.1. Additionally, it is neither possible nor compliant to use CTE and send a content-length header, both because the length would be wrong and because this is forbidden in RFC 2616, section 4.4, part 3. Any system claiming to support HTTP/1.1, yet requiring a Content-Length in all cases, fails RFC 2616 compliance for that reason.