Project

General

Profile

Actions

Feature #16731

closed

Cache-Control Headers do not address client-side caching

Added by Ekkehard G¼mbel about 18 years ago. Updated about 11 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2006-11-21
Due date:
% Done:

0%

Estimated time:
PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

I am struggling to prevent my friend the IE from caching locally...
Normally, that is done using HTTP headers. TYPO3 supports these with the "sendCacheHeaders" config option, and it behaves just like TSRef says: "In case caching is not allowed, these headers are sent to avoid client caching: Cache-Control: private"

Now "Cache-Control: private" is fine for shared proxy caches but not for client side caching (see http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html).

What it takes is to send additional headers, at least "Expires:"
(There are other options that could be used, while this one is preferred.)

To address all purposes (enable or disable client caching), IMHO the behaviour should be toggable.
Funny thing is, that in class.t3lib_userauth.php an internal variable called "sendNoCacheHeaders" seems to take care of this issue.

Extending this concept to a TS switch for class.tslib_fe.php is solving the problem - patch is attached.

Bottom line is:
sendNoCacheHeaders = 0 : prevent shared (a.k.a. proxy) caching, allow client (a.k.a. browser) caching. This was Ole Tange's sole intention when introducing sendCacheHeaders, as he just told me.

sendNoCacheHeaders = 1 : prevent all caching

[Another option would be to change "sendCacheHeaders" (without the "No") from boolean to multiple value or even bitmask, but I'd tend to avoid this.]
(issue imported from #M4541)


Files

class.tslib_fe.php.patch (998 Bytes) class.tslib_fe.php.patch Administrator Admin, 2006-11-21 13:08
Actions

Also available in: Atom PDF