[MAGNOLIA-2495] Selectively switch off the gzip compression based on user agent Created: 05/Dec/08 Updated: 23/Jan/13 Resolved: 07/Jan/09 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | cache |
| Affects Version/s: | 3.6.3 |
| Fix Version/s: | 4.0, 3.6.4, 3.6.5 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Jan Haderka | Assignee: | Jan Haderka |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Template: |
|
||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||
| Date of First Response: | |||||||||||||
| Description |
|
Due to issues with IE6, implement change cache configuration to selectively disable gzip compression for JS and CSS resources. Doing so allows to work around buggy gzip support in IE6 without having to switch off the compression or caching completely. |
| Comments |
| Comment by Philipp Bracher [ 05/Dec/08 ] |
|
ideally this voter would fire only if the client is IE6 since this causes a performance loss |
| Comment by Philipp Bracher [ 05/Dec/08 ] |
|
Btw gzip configuration should be centralized (used by both the cache and gzip filter). It must not necessarily bypass the cache (if the cache serves the plain content in that case). |
| Comment by Jan Haderka [ 05/Dec/08 ] |
The issue here is completely different configuration mechanism used by gzip and by cache. GZip relies completely on the filter bypass logic to decide when to fire and when to skip, while cache needs to kick in even when content should not be compressed and has to decide only later when storing content in the cache and again when serving it from the cache.
We could perhaps streamline it by letting both Store executor and GZipFilter to use same set of Voters to decide if content should be gzipped. |
| Comment by Philipp Bracher [ 05/Dec/08 ] |
|
This is exactly what I mean: 2) the voters for gzip should be centralized (cache and filters)
I really strongly believe that those things must stay, resp. become cleaned up. |
| Comment by Jan Haderka [ 05/Dec/08 ] |
|
Actually more complete list of scenarios is:
To serve the content compressed or flat you need to take in account user browser (user-agent and contentEncoding headers) The only clean separation is to make cache ignore compression issue all together and have GZipFilter the only place evaluating this. We discussed it earlier if you remember and decided that performance hit due to repeated compression of content would be too big and unnecessary. If we centralize the configuration (and I'm all for it, I don't like to have to configure it in two places any more then you), the configuration of voters should IMHO reside in the cache module, rather then in one of the filters since they can be turned on/off or even removed interdependently. |
| Comment by Jan Haderka [ 05/Dec/08 ] |
|
To summarize:
In case I've forgotten something from what we discussed please let me know. |
| Comment by Jan Haderka [ 07/Jan/09 ] |
|
Done in trunk as of r20990 and on 3.6 branch as of r21038. |