[
http://jira.magnolia.info/browse/MAGNOLIA-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gregory Joseph updated MAGNOLIA-2177:
-------------------------------------
Summary: When caching (1st request), we're always serving the gzip'd
content, even if the client does not accept gzip encoding (was: When caching,
we're always serving the gzip'd content, even if the client does not accept
gzip encoding)
> When caching (1st request), we're always serving the gzip'd content, even if
> the client does not accept gzip encoding
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: MAGNOLIA-2177
> URL: http://jira.magnolia.info/browse/MAGNOLIA-2177
> Project: Magnolia
> Issue Type: Bug
> Components: cache
> Affects Versions: 3.6
> Reporter: Gregory Joseph
> Assignee: Gregory Joseph
> Fix For: 3.6
>
>
> 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 ...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.magnolia.info/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/
----------------------------------------------------------------
