Content-Length with invalid value causes error 400

[pauljosh]

Hi, 

Good day!

I have encountered a scenario wherein whenever I send an xml payload in gzip format apigee appears to have some challenges regarding the content length. 

Here's what I had observed. 

When sending the request the http header Content-Length is able to reflect the gzip file size which is 243 bytes. But the reflected payload is the xml payload in the request content section in which the xml payload decompressed has a size of 392 bytes. 

Within the debug session logs, I noticed that on the "request sent to target server" section the content-length is not visible and the xml payload with 392 bytes is reflected. This lead me to suspect that the potential conflict is the content-length https header value that could probably not aligned properly with the payload being processed/sent.

Can anyone provide additional inputs and clarification to this issue? 

According to this document (http://apigee.com/docs/api-services/reference/endpoint-properties-reference) and community post (Solved: Does Apigee support compression/de-compression wit... - Google Cloud Community), compression and decompression is handled automatically by apigee during the API call. This being the case, I'm wondering if the content-length is also updated accordingly during the API request call? Because there is no explicit sign of this within the apigee debug logs. 

All inputs and clarifications are much appreciated!

Thank you all in advance!

[pauljosh]

Posting a conclusion on this post. 

The issue has been resolved. It appears that the content length http header value is not automatically being managed during the decompression of a gzip file. I've implemented a workaround to recalculate and reassign the value of the http header content-length to align it with the payload before sending it to the target endpoint.