[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:
dependency
is depended upon by MAGNOLIA-2334 GZip encoding of js and css resources... Closed
relation
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 ]

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).

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.
It is actually even more convoluted:

  • GZipFilter relies on its bypass configuration and on value returned by RequestHeaderUtil.acceptsGzipEncoding(request)
  • Store executor relies on its list of compressible content types to instruct CachedPage whether to compress content in the cache
  • UseCache executor relies on the RequestHeaderUtil.acceptsGzipEncoding(request) and on the fact that content in the cache is zipped (or not)

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.
If we do this, there is still the problem where/how to check and decide on the compression based on the User-Agent. If we harmonize the configuration as described above, then we have a problem since in this case we want to have content compressed by Store executor, but skipped GZipFilter and by UseCache so the voter would not work here.

Comment by Philipp Bracher [ 05/Dec/08 ]

This is exactly what I mean:
1) don't mix the decision if content should be cached and if the content should be gzipped. The following scenarios are valid
a) cache and gzip
b) cache but don't gzip
c) gzip but don't cache
d) neither cache nor gzip

2) the voters for gzip should be centralized (cache and filters)

  • the filter could us a bypass which falls back on those voters
  • we might even split the module (gzip and cache which then bases on the former)

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:

  1. cache flat and compressed (Store + UseCache)
    1. and serve back COMPRESSED
    2. and serve back flat
  2. cache flat and serve flat (Store + UseCache)
  3. do not cache and serve compressed (Bypass + GZipFilter)
  4. do not cache and serve flat (Bypass executor and bypass on GZipFilter)

To serve the content compressed or flat you need to take in account user browser (user-agent and contentEncoding headers)
To compress content when creating the cache you need to take in account whether content type is compressible (html, js, css) or not irrespective of browser to which content will be served.

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.
We will also need to split different concerns here (creating compressed content entry from serving compressed content).

Comment by Jan Haderka [ 05/Dec/08 ]

To summarize:

  1. compression configuration will be located in the /modules/cache/compression/bypasses and both GZipFilter and UseCache executor will load it from there.
  2. there will be two voters configured
    1. ContentType - similar to what is now configured directly in the GZipFilter
    2. UserAgent - neow voter to deal with the issues related to browser problems (IE6)
  3. the Store executor will evaluate onlt ContentType voter when deciding whether to create compressed content entry or not. Uncompressed content cache entries will not be affected by this at all
  4. Existing configuration of bypasses in the GZipFilter will be replaced by DelegateVoter which will execute compression configuration voters from the new location in /modules/cache/compression/bypasses
  5. Existing configuration of compressible content types from Store executor will be removed and instead ContentType voter from /modules/cache/compression/bypasses/ContentType will be used.

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.

Generated at Mon Feb 12 03:37:16 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.