How to configure Gzip compression in CXF

Issue

By default, CXF on Fuse will neither decode Gzip-compressed HTTP responses from external webservers, nor encode using Gzip when its own HTTP clients request it.

When Fuse/CXF is used as a client, this misconfiguration does not result in any specific CXF exception being thrown. Instead, Gzip-compressed data will enter the next stage of processing, where the failure mode will depend on the application. Most likely, errors will be reported by the XML parser, such as "Content not allowed in prolog" or "Invalid byte sequence". This is because the parser is expecting uncompressed data.

When Fuse/CXF is used as a server, then the lack of Gzip support will not cause a failure, necessarily -- rather, the client will receive uncompressed data when it might have expected compressed data. The client will probably be able to cope with this. However, Camel routes generally propagate what headers they can from consumer to producer endpoints. So if a client of Fuse/CXF requests Gzip encoding, this might cause Fuse/CXF to request Gzip encoding from downstream servers.

If CXF logging interceptors are enabled, you might see "gibberish" for the message payload, because the Gzip data is not being decompressed.

Problems of this kind can begin unexpectedly, as external services change their reliance on Gzip compression.