[MAGNOLIA-2177] When caching (1st request), we're always serving the gzip'd content, even if the client does not accept gzip encoding Created: 09/Jun/08 Updated: 02/Feb/15 Resolved: 01/Sep/08 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | cache |
| Affects Version/s: | 3.6 |
| Fix Version/s: | 3.6.2, 3.6.3 |
| Type: | Bug | Priority: | Major |
| Reporter: | Magnolia International | Assignee: | Jan Haderka |
| Resolution: | Fixed | Votes: | 1 |
| 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)
|
||||||||||||||||||||
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||
| Description |
|
Currently (i.e in trunk, since cache has been rewritten, not in 3.5.x), when the cache policy determines the entry needs to be cached, the cache filter always serves the gzipped content (assuming the gzip filter is enabled), even if the client does not accept gzip encoding (even the gzip filter is enabled, of course). The GZipFilter should ideally stay client-agnostic: as per its javadoc, the cache filter can then assume that whatever it will cache can be gzipped, and should be unzipped if needed. If we changed this, the cache filter could not assume anything about it, and the CachePolicy would therefore need to be aware of gzipping. One relatively easy fix would be to do like the ehcache web filters do: defer the writing of the response and only write it once it's been cached: instead of, as we currently do, let the normal filter chain write it and then cache the results, we could run along the filter chain until we get a CachedEntry and then write it out just like when the cache policy says we should useCache. This might have performance or memory usage impacts, but probably nothing more than we using the cache for other requests? We'd missing the streaming that a normal filter could do, but that is already the case when serving cached elements afaik ... |
| Comments |
| Comment by Magnolia International [ 14/Jul/08 ] |
|
Not ready to change this for 3.6, will have to live with this bug until 3.6.1 - browsers can handle this as far as I can tell. |
| Comment by Jan Haderka [ 01/Sep/08 ] |
|
r17777, r17778, r17779 |