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
| Workflow | Original: Simplified Crowd Development Workflow v2 - restricted [ 1509936 ] | New: JAC Bug Workflow v3 [ 3364851 ] |
| Status | Original: Resolved [ 5 ] | New: Closed [ 6 ] |
| Workflow | Original: Simplified Crowd Development Workflow v2 [ 1392524 ] | New: Simplified Crowd Development Workflow v2 - restricted [ 1509936 ] |
| Workflow | Original: Crowd Development Workflow v2 [ 273662 ] | New: Simplified Crowd Development Workflow v2 [ 1392524 ] |
| Workflow | Original: JIRA Bug Workflow v2 [ 174448 ] | New: Crowd Development Workflow v2 [ 273662 ] |
| Regular Expression | New: com\.ctc\.wstx\.exc\.WstxIOException: Invalid UTF-8 start byte |
Justin Koke
made changes -
| Workflow | Original: jira [ 150554 ] | New: JIRA Bug Workflow v2 [ 174448 ] |
David O'Flynn [Atlassian]
made changes -
| Resolution | New: Fixed [ 1 ] | |
| Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
David O'Flynn [Atlassian]
made changes -
| Fix Version/s | New: 2.0 [ 12269 ] |
David Yu
made changes -
| Description |
Original:
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.
{code} Content-Encoding: Vary: {code} 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 should 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: [ 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. |
New:
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.
{code} Content-Encoding: Vary: {code} 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: [ 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. |
