Problem

API Gateway/Manager appears to be decompressing (inflating) gzip content and then deflating it again before forwarding it to the backend. This process can introduce overhead and potentially degrade performance, especially for large files.

Such behavior is indicated by the presence of DEBUG traces in the logs, such as:

inflated 1 byte to 1024 bytes (102400%)

Resolution

The behavior is related to how HTTP headers for content encoding are interpreted and handled. When the request includes a Content-Encoding header, it indicates that the body of the request has been compressed using gzip. API Gateway will recognize this and automatically decompress (inflate) the body of the request before processing it further or forwarding it to the backend server. This is because the gateway needs to understand and possibly inspect or modify the request content, which requires decompressing it.

To prevent this behavior, consider using the Accept-Encoding header instead of the Content-Encoding header because when the request includes an Accept-Encoding header, it specifies the types of content encodings the client can handle in the response (e.g., gzip, deflate).

This header is intended for use in responses, not requests. Therefore, API Gateway will typically forward the request, including the Accept-Encoding header, to the backend server without altering the request body. The backend server can then decide if it wants to compress the response body using one of the encodings specified in the Accept-Encoding header.

Example:

Instead of using the Content-Encoding header with your cURL request:

curl -v -H "Transfer-Encoding: chunked" -H "Content-Encoding: gzip" --data-binary @large_file --compressed https://<APIGW>:<PORT>/test

You should use the Accept-Encoding header instead:

curl -v -H "Transfer-Encoding: chunked" -H "Accept-Encoding: gzip" -H 'Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryTkU5v9FuDALZUcGn' --form 'uploadfile=@"large_file"' --compressed https://<APIGW>:<PORT>/test