ZF-4632: Zend_Cache_Frontend_Page cannot handle contents with client dependend content-encodings
Description
I deliver the page content in gzipped format, if the browser supports this. So every page can have to versions, a standard version and a gzipped one. The problem is, that you'll see the gzipped content instead of the webpage if the browser doesn't support this encoding (but the browser before supported it, so that the content has been cached gzipped).
At the moment it's not possible to tell Zend_Cache_Frontend_Page to differ between both versions, as the info if gzip encoding is supported is contained in the $_SERVER variable - and there's no option to use the $_SERVER variable for the cache key generation.
I don't know what would be best - an option to include the client encoding, the complete $_SERVER variable or a general option to set own variables, to influence the cache key. At the moment I use a workaround by setting an additional $_GET variable.
To test this, simply save an gzip encoded page in the cache and reload the page with a manipulated header (e.g. by changing "network.http.accept-encoding" in the Firfox configuration). Of course also the "content-encoding" has to be added to the "memorize_headers" option.
Comments
Posted by Fabien MARTY (fab) on 2008-10-27T11:58:18.000+0000
Ok, I understand the problem
A flexible solution could be to introduce an optional key in Frontend_Page API to influence the generated cache id
In your particular case, you would be able to set this key to a value like md5($yourServerVariable) and so, you will have different cache id depending on the client capabilities
what do you think about this proposal ?
Posted by Christoph Ziegenberg (ziegenberg) on 2008-10-28T07:26:07.000+0000
I had a look on the other issues and I'm not sure if the Content-Encoding is a part of the add "httpconditionnal stuff" issue?
But in general, it would be good to be able to influence the key cache with an own variable or an array of variables, as there are many other $_SERVER variables which are user dependend (e.g. "LOGON_USER", "AUTH_USER", "REMOTE_USER").
Posted by Fabien MARTY (fab) on 2009-07-17T11:03:32.000+0000
change Assignee because I'm inactive now
Posted by Arthur Kang (arthurkang) on 2009-08-03T10:00:08.000+0000
I am also in favor of adding more possible variable checks when creating the cache id. I'm running into issues with Translation and User Agent based content. Cached pages are cached in one language based on first user, and any user-agent configs or content is set based on first user as well.
Posted by Rob Allen (rob) on 2012-11-20T20:53:37.000+0000
Bulk change of all issues last updated before 1st January 2010 as "Won't Fix".
Feel free to re-open and provide a patch if you want to fix this issue.