Does Apigee support compression/de-compression with GZIP/deflate compression?
We have a requirement to support compression/de-compression on an Apigee bundle.
I found a link on Apigee specifically below help page:
http://apigee.com/docs/api-services/reference/endpoint-properties-reference
I had a couple of queries around this:
1) Does it actually compress/decompress when I send traffic to Target endpoint? Or does it support the headers related to compression/decompression only?
2) In the scenario, where I get gzip/deflate compressed data, is it possible for my proxy to uncompress this data before sending it to backend target?
3) In the same scenario as above, Can I send the compressed data as is to target endpoint
Any more details like how to validate and test this would be great.
Best Answer
Answer by Mike Dunker @Google
·
Mar 19, 2015 at 04:52 PM
Hi,
Apigee Edge takes care of all compression automatically. As the document you linked to says, by default it will use the compression requested by the client, but you can change that using the target endpoint configuration.
The message is uncompressed when executing the request and response flows -- you never will see compressed data, and this all happens automatically.
You can test this using a test target like httpbin.org. The endpoint http://httpbin.org/gzip returns gzipped data, and you can see what kind of compression was sent to it.
Mike
Thanks @Mike Dunker. The HTTPBin link you posted seems to be "getting" data. Is there a way to do this when I am "posting" data? ie. Verify that the message I am posting to Apigee goes to the target in a compressed format.
Thanks,
Girish
Hi Girish,
You can test this by using another proxy as a test target. Send a request via curl to a proxy and manually set the Content-Encoding header:
curl -X POST -H "Content-Encoding: gzip" "http://{myorg}-test.apigee.net/gziptest" -d '{ "test": "a" }'
Edge will expect gzip'd data. Since curl didn't gzip the data, you'll see the following error from Edge:
{"fault":{"faultstring":"Failed to Decompress","detail":{"errorcode":"messaging.adaptors.http.DecompressionFailure"}}}
Use the Edge proxy as the target. Trace the target proxy, and if you can see the Content-Encoding header set to gzip and can see the payload, then Edge was able to uncompress the data, and the data came in correctly gzip'd.
Note that you typically don't want to call back into an Apigee proxy from another Edge proxy in the same org. There are performance implications -- see the conversation about proxy chaining here: http://community.apigee.com/questions/1260/api-chaining.html . Just for testing is OK.
Mike
Thanks @Mike Dunker. I was successfully able to test the compression and decompression with the "right" headers and "route rules".
Thanks,
Girish
Hi @Mike Dunker ,
Apigee documentation says , for Transport Property, Compression.Algorithm supported values are gzip,deflate and none.
Does that mean Apigee dont support br i.e. compression using Brotli algorithm?
We have a requirement where we need to support all compression algorithms (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding), so checking if we need to explicitly do something to support br .
Thanks,
Anoop
What if a backend always responds with gzip, but the use-case is for Apigee to always respond with the decompressed response?
I have tried adding <Property name="compression.algorithm">none</Property> to the Proxy Endpoint as well as Target Endpoint to no avail.
In all cases, the response come back as gzipped.
Thanks.
Same here, my node app gzip it and looks like Apigee gzip again before it got returned to client. If I curl url | gunzip | gunzip I see what is expected.
I'm seeing the same thing @Louis.lim5 - someone in this thread: gzip problems implies it may be a known problem with a fix coming. Don't suppose you've found a solution already?
Hello
| Louis-Etienne.Dorval |
I think what might work for you in this case is,
> Do not enable/set compression in your nodejs code, so nodejs returns uncompressed response.
> In Edge Proxy - in the response flow - Add a header 'Content-Encoding: gzip' to your response using "AssignMessage" policy
Let me know if this workaround works for you
Thanks,
Mukundha
For the records, my question was basically: I'm using the NodeJS integration with Apigee Edge and the compression doesn't work.
Thanks @Mukundha Madhavan it's working perfectly now !
if the response received from System SouthBound to APIGEE is uncompressed , can we configure APIGEE to compress the response before its sent to the client?
yes , you can compress response .
You have to add header in response flow , attach below Assign Message in response flow -
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage async="false" continueOnError="false" enabled="true" name="AM-Set-Compress-Response">
<DisplayName>AM-Set Compress Response</DisplayName>
<Add>
<Headers>
<Header name="Content-Encoding">gzip</Header>
</Headers>
</Add>
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
<AssignTo createNew="false" transport="http" type="request"/>
</AssignMessage>
@Sartaj Singh Sisodiya, Do you know a way to decompress the response using assign message policy? Our backend always responds with a gzipped response.
In the case where a backend target returns compressed data and you want to un-compress it before sending to client, you can do so easily by using an Assign Message in the response flow.
For example using httpbin.org/gzip as the backend for testing.
curl -i https://ORG/proxy/gzip -H "Accept:application/json"
Add the following condition in the response flow:
<Response>
<Step>
<Condition>(request.header.accept = "application/json") and (response.header.content-encoding = "gzip")</Condition>
<Name>AM-ZipResponseInflate</Name>
</Step>
</Response>
Then the Assign Message policy is:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage async="false" continueOnError="false" enabled="true" name="AM-ZipResponseInflate">
<DisplayName>AM-ZipResponseInflate</DisplayName>
<Set>
<Headers>
<Header name="Content-Type">application/json</Header>
</Headers>
<Payload contentType="application/json">{response.content}</Payload>
<StatusCode>200</StatusCode>
<ReasonPhrase>Inflated Response</ReasonPhrase>
</Set>
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
<AssignTo createNew="true" transport="http" type="response"/>
</AssignMessage>
NOTE: the use of createNew="true"
