PHP Doku:: Liefert und/oder setzt die aktuelle Cacheverwaltung - function.session-cache-limiter.html

Verlauf / Chronik / History: (1) anzeigen

Sie sind hier:
Doku-StartseitePHP-HandbuchFunktionsreferenzSession-ErweiterungenSessionbehandlungSession-Funktionensession_cache_limiter

Ein Service von Reinhard Neidl - Webprogrammierung.

Session-Funktionen

<<session_cache_expire

session_commit>>

session_cache_limiter

(PHP 4 >= 4.0.3, PHP 5)

session_cache_limiterLiefert und/oder setzt die aktuelle Cacheverwaltung

Beschreibung

string session_cache_limiter ([ string $cache_limiter ] )

session_cache_limiter() gibt die Bezeichnung der aktuellen Cacheverwaltung zurück.

Die Cacheverwaltung definiert, welche Cache-Kontroll-HTTP-Header, zum Client geschickt werden. Diese Header bestimmen die Regel, nach der der Seiteninhalt von Client und dazwischenliegenden Proxies in den Cachespeicher aufgenommen werden darf. Wird die Cacheverwaltung auf nocache gesetzt, so ist eine client-/proxyseitige Speicherung im Cache nicht erlaubt. Der Wert public erlaubt die Aufnahme in den Cachespeicher durch Proxies und den Client, wohingegen private Proxies die Speicherung im Cache verbietet und dem Client erlaubt, den Seiteninhalt im Cache zu speichern.

Im private-Modus könnte ein zum Client gesendeter Expire-Header manche Browser, inklusive Mozilla, verwirren. Sie können dieses Problem durch Verwendung des private_no_expire-Modus vermeiden. In diesem Modus wird nie ein Expire-Header zum Client gesendet.

Zu Beginn einer Anfrage wird die Cacheverwaltung auf den voreingestellten Wert zurückesetzt, der in session.cache_limiter gespeichert ist. Daher müssen Sie session_cache_limiter() bei jeder Anfrage aufrufen (und zwar bevor session_start() aufgerufen wird).

Parameter-Liste

cache_limiter

Wenn cache_limiter angegeben wurde, wird diese dem neuen Wert entsprechend geändert.

Mögliche Werte
Wert Gesendete Header
public
Expires: (entsprechend session.cache_expire irgendwann in der Zukunft)
Cache-Control: public, max-age=(entsprechend session.cache_expire irgendwann
                                in der Zukunft)
Last-Modified: (der Zeitstempel der letzten Session-Speicherung)
private_no_expire
Cache-Control: private, max-age=(session.cache_expire in der Zukunft),
               pre-check=(session.cache_expire in der Zukunft)
Last-Modified: (der Zeitstempel der letzten Session-Speicherung)
private
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: private, max-age=(session.cache_expire in der Zukunft),
               pre-check=(session.cache_expire in der Zukunft)
Last-Modified: (der Zeitstempel der letzten Session-Speicherung)
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

Rückgabewerte

Gibt die Bezeichnung der aktuellen Cacheverwaltung zurück.

Changelog

Version Beschreibung
4.2.0 Die Cacheverwaltung private_no_expire hinzugefügt.

Beispiele

Beispiel #1 session_cache_limiter() Beispiel

<?php
/* setzen der Cacheverwaltung auf 'private' */
session_cache_limiter('private');
$cacheverwaltung session_cache_limiter();
echo 
"Die Cacheverwaltung ist jetzt auf $cacheverwaltung gesetzt<br />";
?>


33 BenutzerBeiträge:
- Beiträge aktualisieren...
Tomas Liubinas
14.03.2010 23:24
FALSE parameter disables any automatic cache limiter
In this case no additional headers are sent

<?php
session_cache_limiter
( FALSE );
?>
ire dot ogunsina at gmail dot com
1.10.2008 16:55
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:
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Expires" CONTENT="-1">

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.
yves at kochira point com
8.09.2008 10:58
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').
scott at realorganized dot com
2.05.2008 8:03
http://us.php.net/session_cache_limiter

sends:

Pragma: no-cache

under some conditions from server to client.

Internet Explorer has a strange interpretation of: Pragma: No-cache
being sent from the server to the client. 

Here's the link:

http://support.microsoft.com/kb/234067

If the client communicates with the server over a secure connection (https://) and the server returns a Pragma: no-cache header with the response, Internet Explorer does not cache the response.

Note, however, that the Pragma: no-cache header was not intended for this. According to the HTTP 1.0 and 1.1 specifications, this header is defined in the context of a request only, not a response, and is actually intended for proxy servers that may prevent certain important requests from reaching the destination Web server. For future applications, the Cache-Control header is the proper means for controlling caching.

For this reason, watch out when using the Pragma: no-cache with https and IE
clay at killersoft dot com
30.03.2008 15:44
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.
david at ordal dot com
25.03.2008 23:28
We did quite a lot of trial and error testing in IE 6/7 and FireFox 2.X to see what magic combo worked so that
1) the browser would cache the state of the page, but
2) The browser or intermediate proxies wouldn't cache the entire page.

Thus a NEW request would reload the page, but back/forward browser navigation wouldn't force a reload.

We found this worked best across browsers:

session_cache_limiter ('private_no_expire, must-revalidate');
brinley at etcorp dot com
31.08.2007 5:30
For those people trying to fix IE6's problem of recognizing the filename attribute in Content-Disposition. I thought I'd add that in addition to the fixes mentioned before, you have to take note of invalid and sensitive characters in the file name. For example, having a space or colon in the filename will cause IE6 to use a randomly generated filename.
Typer85 at gmail dot com
13.07.2007 11:16
Here is another handy trick for your session lovers out there;

It seems that using 'nocache' as an argument for this function, will prevent users browsing your website using IE 6 from viewing your HTML source file!

Probable reason ... probably because IE 6 is not caching anything due to the headers it is receiving, see my post below this one, and since IE 6 by default loads HTML source files from its cache, it can not find a file to open using notepad, since no file will exist in the cache!

I am not sure if this is the same with IE 7, but Mozilla Firefox does not have this problem.

Thank you Microsoft for yet another 'quality' product ( I read that somewhere and thought it was funny) ... at least now someone has a pretty neat trick up there hand to hide away their HTML source.

Do not know who ... but you are out there I am sure :)
Typer85 at gmail dot com
13.07.2007 10:19
Here is some magic for you PHP session lovers out there;
it seems that if you use 'nocache' as an argument for this function, PHP will send the following headers automatically for you:

--------------

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Pragma: no-cache

--------------

Which pretty much render any cache ineffective because no proxy or browser that follows the HTTP 1.1 protocol will cache
your request. In short, every page request, whether explicitly through a page reload or not, will go through your server.

Not something good for those of us looking for a bit of security but also for some performance juice.

The only way to override these headers, if you use the 'nocache' as an argument, is to use the header( ) function
after you start your session but before you send any output:

<?php

// Above Headers Sent By PHP.

session_cache_limiter( 'nocache' );

// Start Session.

session_start( );

// Override Headers.

header( 'Cache-Control: no-cache, must-revalidate, post-check=3600, pre-check=3600' );

?>
Fernando Gabrieli fgabrieli at gmail
7.04.2007 14:21
<?
    session_cache_limiter
('private, must-revalidate');   

   
$cache_limiter = session_cache_limiter();

   
//

   
session_cache_expire(60); // in minutes

   
session_start() ;
?>

If i do not set must-revalidate, IE seems to cache session variables without refreshing them

If i post a form then it refreshes the variables

Firefox does not have this problem

So, be sure to use must-revalidate
Jeremiah at jkjonesco dot com
31.10.2006 0:20
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.
john
28.03.2006 18:36
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.

19.10.2005 17:11
The onLoad method of Actionscript's loadVars class was returning false in IE6 using SSL until I set --> session_cache_limiter("must-revalidate"); <-- on the receiving PHP script.
radu dot rendec at ines dot ro
18.10.2005 13:41
I've read the other comments and done some "reasearch" on my own. Using php's session mechanism and explicitly setting the "cache-control" header should not be mixed.

When session_start() is called, the "cache-control" and "pragma" headers are automatically set by php (to whatever value had been specified using session_cache_limiter()).

Explicitly setting those headers _before_ session_start() will have no effect, and explicitly setting them _after_ session_start() will overwrite the settings from session_cache_limiter().

If I had to deal with php sessions, I'd go for using session_cache_limiter() and leaving the headers alone.

3.09.2005 0:04
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!
donovan at go4 dot com dot au
8.08.2005 3:41
IE6 'the file could not be written to the cache':

I tried all the other suggestions mentioned here but none of them worked.

I friend suggested header("Pragma: ");

This worked straight away!
snakes at ntica dot com
12.05.2005 23:28
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");
?>
Andrei Chirila, andrei_chirila at yahoo dot com
12.01.2005 15: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 ...
justin at justintubbs dot com
7.01.2005 21:04
I have PHP 4.3 running on a Windows 2003 Server running IIS 6.0 also using SSL encryption for my pages.  I could not (for the life of me) figure out how to get IE 6.0/WinXPPro to recognize a set of HTML tables as an Excel spreadsheet export, and it was due to the header() variables I was using.  Hopefully these are helpful to others who are attempting the same type of export within PHP.

*This example builds on the previously submitted one, adding a few necessary headers.

<?php
    header
("Expires: Sat, 01 Jan 2000 00:00:00 GMT");
   
header("Last-Modified: ".gmdate("D, d M Y H:i:s")." GMT");
   
header("Pragma: public");
   
header("Expires: 0");
   
header("Cache-Control: must-revalidate, post-check=0, pre-check=0");
   
header("Cache-Control: public");
   
header("Content-Description: File Transfer");
   
   
session_cache_limiter("must-revalidate");
   
header("Content-Type: application/vnd.ms-excel");
   
header('Content-Disposition: attachment; filename="fileToExport.xls"');

   
// and after you start the session
   
session_start();
?>
pulstar at ig dot com dot br
24.10.2004 23:39
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:

<?php

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.
misterp3d at hotmail dot com
18.05.2004 23:16
I had a problem using a FORM with POST method when user of my website was using the back button. The page requested a refresh to be able to see again the FORM.

To solve the problem I used :
<?php
session_cache_limiter
('private, must-revalidate');
?>

*You need to write this line before any output

Hope that will help some of you ;)

[P]
usenet at phord splat com
26.03.2004 5:44
Hey!  NickyBoy was right!

I looked all over google and his note was the only place that had it right.  But, there's a caveat.

I wrote up my results here:
http://www.phord.com/experiment/cache/
richard at izyn dot co dot nz
2.03.2004 3:17
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.
Mikko Hämäläinen
22.01.2004 18:10
I had a similair problem (browsers couldn't save files coming from my download-script). Only in my case the problem occured with IE 6.0 and Netscape 7.1. Adding the "session_cache_limiter('public');" before "session_start();" helped.
jthome at fcgov dot com
4.12.2003 1:36
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).

For example:

<?php

        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!!

?>

Best,

--
Jim
plyrvt at mail dot ru (Yura Pylypenko)
31.07.2003 23:33
Be careful using session_cache_limiter() with ob_start('ob_gzhandler')
If ob_start('ob_gzhandler') is called after session_cache_limiter() it seems to overwrite cache control headers with 'nocache' equivalent.
So always put ob_start first.
MerlinsInvite
23.05.2003 18:51
I solved the problem with pushing downloads to browser's, without needing to play with server/session parameters by using :
header("Content-Disposition: inline; filename=\"$filename\"");
for IE browsers and
header("Content-Disposition: attachment; filename=\"$filename\"");
for all other browsers.
nickyboy at 4ce.co.uk
11.03.2003 2:42
The problems people mention about IE are actually a feature! 
Microsoft Knowledge Base Article 316431 says:

In order for Internet Explorer to open documents in Office (or any out-of-process, ActiveX document server), Internet Explorer must save the file to the local cache directory and ask the associated application to load the file by using IPersistFile::Load. If the file is not stored to disk, this operation fails.

When Internet Explorer communicates with a secure Web site through SSL, Internet Explorer enforces any no-cache request. If the header or headers are present, Internet Explorer does not cache the file. Consequently, Office cannot open the file.

They say this applies to:
Microsoft Internet Explorer 5.5 for Windows 2000
Microsoft Internet Explorer 5.01 for Windows 2000
Microsoft Internet Explorer version 6 for Windows 2000
not sure about other versions!

hth
nickyboy
phobo at paradise.net.nz
13.12.2002 2:33
Please note that you DO NOT NEED to specify session_cache_limiter to get downloads work IMHO.

With IE6 (and others I imagine), you might have a problem with the filename attribute of Content-Disposition being recognised. In my experience, IE always believed the filename of the download was the name of the script (ie, the URL generating the file, rather than the header being pushed).

When adding: Header("Pragma: public");   this was solved.

E.g. (Working CSV / opens in Excel in Windows).

--

header("Cache-control: private");
header("Content-Type: text/plain");
header("Content-Disposition: attachment; filename=\"$filename\"");
header("Pragma: public");

echo "Dogs,Cats,Fish\n";
echo "1,2,3\n";
echo "4,5,6\n";

--
cj at NOSPAMceejayoz dot com
18.06.2002 20:41
Setting session.cache_limiter = none; in your php.ini file will avoid the problem in IE in which pressing the back button after using a POST form will result in "Warning: Page Has Expired".
chris at cwcomputerservices dot co dot uk
20.05.2002 20:40
IMPORTANT - READ THIS TO SAVE A LOT OF WASTED TIME

After spending a long time trying all the above solutions without success, I eventually found a more likely cause for these errors. There are problems with Apache/SSL and Internet Explorer with SSL connections - detailed information and a simple fix is here:

http://www.extremetech.com/article/0,3396,s=201&a=24899,00.asp

and here:

http://www.modssl.org/docs/2.8/ssl_faq.html#ToC49

So a simple web server reconfiguration may save you hours of fiddling with cache control headers!
roblugt at elcel dot com
10.10.2001 3:04
We had a strange problem with zip file downloads (not using SSL) under IE5.  If the user chose the option to "save to disk", then everything worked fine, but if they chose "open", then winzip was launched okay - but the displayed zip archive was empty.

We eventually tracked this down to the Cache-Control header and the php script was fixed by adding

 session_cache_limiter('public');

before the first call to session_register()
simon at ateb dot co dot uk
2.03.2001 19:49
There is a bug(?) in Internet Explorer v5.5 to do with file downloads over a secure (https) web connection when using sessions. If you have a php script which delivers files for downloading by setting headers for the content-type etc. from a URL like this:

getfile.php/filename.ext
- or -
getfile.php?file=/filename.ext

and that script uses sessions, then you must explicitly set

session_cache_limiter('public');

*before* you use
session_start();

otherwise you will get one of the following errors from IE when it attmpts to download the file:

Internet Explorer cannot download filename.ext from name.of.your.webserver
Internet Explorer was not able to open this site. The requested site is either unavailable or cannot be found. Please try again later.

Mmm, this is useful error message isn't it! The other error you will see when right clicking and choosing 'Save Target As...' gives the error

Internet Explorer cannot download filename.ext from name.of.your.webserver
The file could not be written to the cache.

This problem does not occur over unsecure (http) links and files download OK. I don't know why this should be the case, but PHP seems to send an extra no-cache header when using sessions which breaks IE when it is using SSL. Setting the session_cache_limiter turns off this behaviour.



PHP Powered Diese Seite bei php.net
The PHP manual text and comments are covered by the Creative Commons Attribution 3.0 License © the PHP Documentation Group - Impressum - mail("TO:Reinhard Neidl",...)