Post Client Flow setting Transfer-Encoding incorrectly

[#1]

We are trying to return gzip content with the Content-Length header set correctly. Setting Accept-Encoding: gzip on the request is handled correctly on the target endpoint and we do get back a response with Content-Type: gzip. When tracing we can see the response unzipped as apigee automatically unzips it and the Transfer-Encoding is correctly set to gzip.

However the post client flow is setting the Transfer-Encoding header to chunked and removing the Content-Length. How can we prevent this behaviour i.e. simply return Content-Encoding: gzip and maintaining the Content-Length header?

We have unsuccessfully tried using an Assign Message policy to remove the Transfer-Encoding header or setting it to gzip on response post flow.

[dchiesa1]

Are you modifying the payload at all?

Try setting streaming to true in the target; this may allow the content-encoding to remain un-molested.

https://docs.apigee.com/api-platform/develop/enabling-streaming

[#3]

Hi Dino, Thanks for the very fast response!

We are not modifying the payload, which I understand might be problematic if we did - even though our responses will never be more than 10 MB in size.

So I enabled response streaming as you suggested but now I am getting a strange behaviour. Am I correct to assume that if that is enabled the response content is now not shown in trace sessions?

In any case, I now get different response headers reported by Apigee from the one I actually receive with curl. On closer inspection, this is also the case without enabling streaming.

Sending a request with:

Cache-Control: no-cache
Accept-Encoding: gzip

The response Apigee reports is sent to client:

Cache-Control: max-age=1800
Connection: keep-alive
Content-Encoding: gzip
Content-Length: 250
Content-Type: application/json; charset=UTF-8
Date: Tue, 11 Sep 2018 20:17:31 GMT
ETag: f0b64b57db082c4ef44b4c889141ec85

While I receive:

Cache-Control: max-age=1800
Connection: keep-alive
Content-Encoding: gzip
Content-Type: application/json; charset=UTF-8
Date: Tue, 11 Sep 2018 20:17:31 GMT
ETag: "f0b64b57db082c4ef44b4c889141ec85"
Transfer-Encoding: chunked

Differences in bold and italics what the target node API is explicitly setting.

Also, it's worth noting that comparing this to having no streaming in the Proxy Post Client Flow the Content-Length is set back to 0 instead of being removed and Transfer-Encoding is no longer present. But the response headers I receive on my end and the (different) response that tracing reports are identical.

When the data is not compressed i.e. when Accept-Encoding: gzip is not set, we receive back the expected response with or without streaming. Interesting to note that Content-Length is still set back to 0 in the Proxy Post Client Flow if streaming is enabled.

[dchiesa1]

I understand what you wrote, but I don't understand the behavior. What is running in the PostClientFlow? What policies?

Is it possible there is another network device in your environment that is proxying calls, and may be chunking the response?

[#5]

The PostClientFlow is not specified at all, it is just the default behaviour.

I can replicate the same behaviour outside our company network so I don't think it's network related.

[#6]

Hey Dino, thanks for your help. After investigating this further, the issue is with the virtual host we are using. If I use default or secure vhosts that are provided by default the response is not chunked. I will raise a support ticket to resolve this. Thanks again.

[dchiesa1]

WOW, that's interesting. I would like to understand the reason behind that difference. Thanks for the followup.