Medium If you enable GZIP compression, and try to connect a Crowd Client to the Crowd Server, the responses are uncompressed, and the content-encoding is unset.
Content-Encoding: Vary:
Also, by leaving it unset, there is a conflict with mod_deflate + Apache when using mod_proxy where it'll output its headers as "Content-Encoding: , gzip" where the comma confuses the client (although you shouldn't really need mod_deflate if you've enabled gzip in Crowd).
Some searching shows that the problem is in atlassian-gzip, and it also affected JIRA: JRA-15658.
I tested upgrading my atlassian-gzipfilter library to 1.9 and that appeared to fix the problem where the contents were actually compressed, and the headers were properly written.
- was cloned as
-
CWD-1404 Make Crowd Client impersonate a more modern browser (User-Agent header)
- Closed
[CWD-1398] Content-Encoding is unset for SOAP requests
David Yu
added a comment - Testing with 1.6.1-snapshot, the WSDL is compressed now. Did a full test with JIRA <-> Crowd but saw the Content-Encoding was still being returned blank. Will require further investigation.
David Yu
added a comment - Testing with 1.6.1-snapshot, the WSDL is compressed now. Did a full test with JIRA <-> Crowd but saw the Content-Encoding was still being returned blank. Will require further investigation. 
David O'Flynn [Atlassian]
added a comment - Updated to atlassian-gzipfilter;1.9 
The reason why JIRA <-> Crowd Content-Encoding was still not gzipped was due to the Crowd Client's User-Agent header. The gzip filter library checks for a valid User-Agent before it will compress specified in urlrewrite-gzip-default.xml.
The Crowd Client will need to impersonate another Browser "Mozilla/5.0" for example, in order to get compression working.