Issue Type: Improvement Created: 2009-03-24T12:35:55.000+0000 Last Updated: 2012-11-20T20:53:33.000+0000 Status: Closed Fix version(s): Reporter: Tom Van Herreweghe (miljar) Assignee: None Tags: - Zend_Cache
Related issues: Attachments:
Using sessions in an application may have a possibly undesired effect on Zend_Cache_Frontend_Page:
When trying to cache a page via the Zend_Cache_Frontend_Page frontend, and with options cache_with_session_variables = true and cache_with_post_variables = false, then no cache-id will be generated. Reason for this is that the session generates a volatile cookie with a predefined session name. Even if no other data is set in the cookies, then no cache-id is generated. This is expected behaviour, but it may be undesired. After all, if you refrain from using cookies, then you should be able to generate a cache-id.
An improvement should be built into Zend_Cache_Frontend_Page::_makePartialId(). If cache_with_session_variables is true, then the session name ("PHPSESSID" per default) index should not be taken into account when trying to create a partial Id for the $_COOKIES superglobal.
Posted by Dolf Starreveld (dolfs) on 2009-04-04T17:43:47.000+0000
I'd go one step further and say that the namespace meta data (SESSION['_ZF') etc. should also not be taken into account. This too is data that the innocent developer may not be aware of as present in the SESSION array and including it can cause the ID to change for every page.
The problem becomes even more lethal when combined with the various approaches found on the Web to implement an inactivity timeout. All invariably involve setting a "last Activity time" into the session on each request. (Either directly, or indirectly through rememberMe which calls regenerateID, etc.). Each page will cause the serialized version of the SESSION to change, causing a new key, causing a cache miss. All suggested solutions fail for this scenario (meaning they effectively negate the page cache if, for other reasons, the key must depend on the SESSION content).
Another approach involves subclassing Zend_Cache_FrontEnd_Page to generate ids differently, but unfortunately, makeID (called in start), is private, forcing you to completely override start (which is not private), which seems rather inefficient and undesirable.
Posted by Dolf Starreveld (dolfs) on 2009-04-04T18:14:27.000+0000
Pardon in the above comment, the remark about the visibility of makeId pertains to 1.6.x versions.
Posted by Fabien MARTY (fab) on 2009-07-17T11:03:31.000+0000
change Assignee because I'm inactive now
Posted by Rob Allen (rob) on 2012-11-20T20:53:33.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.
Have you found an issue?
See the Overview section for more details.