Deflate HTTP Compression

[Nicolas.Afonso]

Hi folks !

 

A quick question about http compression.

My tests seem to demonstrate that deflate compression is not supported by the Gateway.

Could you confirm me that fact ?

 

Another point, about "passing throught request headers". Is there a manner to see the request.http.headers and their values passed to backend after this filter is applied ? In fact if I audit them with ${request.http.headers} after routing assertion they still contain "old" values ...

 

Thank you

[Nicolas.Afonso]

Hi CA community,

 

FYI after posting a ticket on support they confirm me that gzip compression is not supported by CA API Gateway.

 

About the headers values monitoring, the answer was simple : simply use "Manage Transport Properties/Headers " assertion on your request before routing it. You're then able to log them without problems !

 

Bye

[Anon Anon]

You can also list all of the header values in a request using request.http.allheadervalues without using additional assertions.

[Nicolas.Afonso]

Thank you Eric.

 

I knew this context variable, my main point was to check a specific header value after modifying its value using "passing throught request headers" option in route assertion. If I log it I can only see the old value (before the route option modification).

The good way to do this was to force its value before routing, using the appropriate assertion. Then you're able to check the header value before routing and the previous option becomes useless.

 

Have a nice day

[mogol01]

FYI after posting a ticket on support they confirm me that gzip compression is not supported by CA API Gateway.

 

It's worth mentioning that, as of Gateway version 8.3, Gzip compression and decompression is possible via the Encode/Decode Data Assertion.

 

For details, see the user documentation: https://wiki.ca.com/pages/viewpage.action?pageId=204713669

 

It does not support inflate/deflate out of the box. If that's needed, you may want to reach out to Support to request a Tactical solution for that.

 

Cheers,

Ola

[Nicolas.Afonso]

Hi Ola,

 

Thank you for your suggestion, I will contact support about adding this feature.

 

Have a nice day

[Legacy User]

For Gateway Version 9.0.0 I am seeing a Content-Encoding header returned with a value of 'gzip'.

Testing with SoapUI reports an error because the response is not in gzip format.

I do not have "Compress output" checked in the HTTP Routing Assertion.

The only way I've found to stop that header is to set the cluster property response.compress.gzip.allow=false.

 

Is that an appropriate solution?

[greg munger]

I'm going to reply to this somewhat old thread because it was really confusing.

- the original question was deflate, not gzip, and deflate is not supported.

- I believe gzip compression of the request/response to the gateway is supported as a part of client negotiation. When I run SoapUI requests in 9.2 I get compression by default and I verified that it was actually compressed. This happens without any special configuration in the gateway.

I *think* the encode data assertion makes sense in the communication to a back end server.

 

I don't know when gzip was added, I think at least 8.2 if not far earlier.