session_cache_limiter
session_cache_limiter() returns the name of the current cache limiter.
The cache limiter defines which cache control HTTP headers are sent to the client. These headers determine the rules by which the page content may be cached by the client and intermediate proxies. Setting the cache limiter to nocache disallows any client/proxy caching. A value of public permits caching by proxies and the client, whereas private disallows caching by proxies and permits the client to cache the contents.
In private mode, the Expire header sent to the client may cause confusion for some browsers, including Mozilla . You can avoid this problem by using private_no_expire mode. The Expire header is never sent to the client in this mode.
Setting the cache limiter to » will turn off automatic sending of cache headers entirely.
The cache limiter is reset to the default value stored in session.cache_limiter at request startup time. Thus, you need to call session_cache_limiter() for every request (and before session_start() is called).
Parameters
If value is specified and not null , the name of the current cache limiter is changed to the new value.
Expires: (sometime in the future, according session.cache_expire) Cache-Control: public, max-age=(sometime in the future, according to session.cache_expire) Last-Modified: (the timestamp of when the session was last saved)
Cache-Control: private, max-age=(session.cache_expire in the future), pre-check=(session.cache_expire in the future) Last-Modified: (the timestamp of when the session was last saved)
Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: private, max-age=(session.cache_expire in the future), pre-check=(session.cache_expire in the future) Last-Modified: (the timestamp of when the session was last saved)
Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache
Return Values
Returns the name of the current cache limiter. On failure to change the value, false is returned.
Changelog
Examples
Example #1 session_cache_limiter() example
/* set the cache limiter to ‘private’ */
session_cache_limiter ( ‘private’ );
$cache_limiter = session_cache_limiter ();
echo «The cache limiter is now set to $cache_limiter
» ;
?>
See Also
User Contributed Notes 25 notes
The actual headers that are set using the values described above are:
public:
Expires: pageload + 3 hours
Cache-Control: public, max-age=10800
private:
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: private, max-age=10800, pre-check=10800
nocache:
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
private_no_expire:
Cache-Control: private, max-age=10800, pre-check=10800
Regarding other settings mentioned by some, those just don’t do anything. Check the source of PHP, in ext/session/session.c — the above values are all that actually do anything. Other values, or an emtpy string, result in no cache-limiting headers being set at all.
If you are trying to work with dynamic binaries such as videos or images, the new IE 7 appears to require the ETag header. You will need to make sure that you follow the specifications for how ETag works in order for your cache control to work properly. Mozilla supports the ETag header as well, but does NOT require it for caching. If you need to cache a dynamic image, video, or other binary file, then be sure to set your ETag and then check for the If-Not-Modified header on subsequent requests so that you can properly return the 304 Not Modified page.
I have had some trouble preventing IE, particular IE 7 to stop caching pages. I read quite a number of articles relating to people’s experiences and how they fixed it but it was hard to find one that worked for me. Eventually I had to use the following fix:
based on the information available on following url: http://support.microsoft.com/kb/234067
Would to God that we’d all quit IE for good. Hope this saves someone some agony over IE.
In addition to the above, don’t forget to check the php.ini file for the setting: session.cache_limiter = nocache
Since I use xoops and didn’t start the session, I had the SSL/download problem until I noticed this.
Avoiding caching PHP pages:
After lot of tries and research this is the best combination of headers I’ve found that seems to work well even with the proxy of visitors that are using satellit connection.
header(«ETag: PUB» . time());
header(«Last-Modified: » . gmdate(«D, d M Y H:i:s», time()-10) . » GMT»);
header(«Expires: » . gmdate(«D, d M Y H:i:s», time() + 5) . » GMT»);
header(«Pragma: no-cache»);
header(«Cache-Control: max-age=1, s-maxage=1, no-cache, must-revalidate»);
session_cache_limiter(«nocache»);
?>
I found that session_cache_limiter(«none») works for me when I create PDFs on the fly because session_cache_limiter(«private») causes the browser(IE6) to cache the PDF indefinitely.
In addition to the note above regarding SSL/IE bug/Sessions, also make sure you DO NOT SET THE HEADER ‘Pragma: no-cache’ if you are sending an inline document (e.g., PDF document).
header ( «Content-Type: application/pdf» );
header ( «Content-Disposition: inline; filename=foo.pdf» );
header ( «Accept-Ranges: bytes» );
header ( «Content-Length: $len » );
header ( «Expires: 0» );
header ( «Cache-Control: private» );
// header(«Pragma: no-cache»);//don’t send this header!!
You can find more information about to control the cache in PHP at http://www.php.net/manual/en/function.header.php
If you have a dinamic website and want to allow your visitors to use the back button after they sent a form with the post method, the best combination I found was:
header ( «Expires: Sat, 01 Jan 2000 00:00:00 GMT» );
header ( «Last-Modified: » . gmdate ( «D, d M Y H:i:s» ). » GMT» );
header ( «Cache-Control: post-check=0, pre-check=0» , false );
session_cache_limiter ( «must-revalidate» );
// and after you start the session
session_start ();
?>
I try some combinations using header(«Cache-Control: no-cache, must-revalidate»), but when clicking the back button, the last changes in the form back to their previous states. The combination above works fine with IE 6.x. I didn’t test this with other browsers.
When I try something like session_cache_limiter(«nocache, must-revalidate») it doesn’t work. The page only updates when I used the browser’s refresh button. In dynamic web sites this is not good. The content must be fresh after each click.
I didn’t find these combinations like «private, must-revalidate» documented in the manual and I guess that something different from «none, nocache, private, public and private_no_expire» are resolved to «none» or something like that. One thing I notice is that in session_cache_limiter() it is «nocache», but in header() it is «no-cache». This may give us some clues about how session_cache_limiter() function works.
About caching, the perfect solution I think is to give the correct expiration date and time and also the right last-modified header for each element in the web site, when they are really updated. This means a lot of extra controls of course, but may worth in web sites with high overload.
The «public» option means that all available cache in proxies and clientes will be used, so this improves the speed of the web site and also reduces the used bandwidth. But without the right expiration and last-modified headers, you can use it only in static web sites.
The «private» option means that only the cache in clients will be used. This is good for a more sensitive data that can be stored locally in the browser cache. It have some benefits of the public option, but the same restrictions too.
The «nocache» (or no-cache?) option means that the HTML portion will not be cached, but the images, CSS and JS files will. This is good for dynamic websites because you still can use the power of cache without loose the refreshness after each click. These files can be updated when you open the web site or use the browser’s refresh button.
I don’t know why, but flash files are never updated when you click the refresh button. A common solution for this is to change the file name when you update the flash file.
The «no-store» option means that all the content will not be cached anyway, including images, CSS or JS files. I don’t know if this applyes to flash files too, but is possible. This option must be used with very sensitive data. I think the SSL uses this by default.
I was having a fit trying fix an issue caused by session.cache_limiter. Somehow I had set this to nocache (a long time ago) in the .ini file and this setting caused the back-button to not work. When session.cache_limiter was set on private or public, the back-button worked, but then logging out of the site did not work. I had thought that session.cache_limiter was something that should be enabled, but finally found today that turning it off (by setting it to ») fixed both these problems. So now the question for me is, when would anybody ever want to use session.cache_limiter? I was hating Php because of this problem.
To avoid a headache while trying the various parameters in Firefox 3.0.1 (+Firebug), just restart the browser after a change. or they’re not taken into account (from ‘no-cache’ to ‘public’/’private’).
Andrei Chirila, andrei_chirila at yahoo dot com
12-Jan-2005 09:30
I played about an hour with the download and sessions. yes, to work you’ll need session_cache_limiter(«must-revalidate»); but this BEFORE session_start() if you want that your download start [IE problem]. Hope someone will need this someday
yes, somebody has needed this today 🙂
situation: trying to make a session based download management system complete with user login system that requries an authorized user to download some files, and hide all such files from non-authorized users. the user login, download center, and content management system of the site are all tied in to each other, making troubleshooting this headering stuff a headache.
problem: files being served are not accessible thru the regular site, since they are above the htdocs folder in apache, and so headering the file is required, and sessions do not work well with files being headered to the browser.
solution: the download center uses ob_start(«»);, then session_cache_limiter(«must-revalidate»);, before the session_start();, then everything works well.
thank you very much! i was resorting to using a cookie to control this before because i could not figure out how to tie in sessions to the system before!