[TYPO3-dev] Core Behaviour: Using Cache-Control Headers to prevent _Clients_ from Caching

Martin Kutschker Martin.Kutschker at n0spam-blackbox.net
Tue Nov 21 14:24:55 CET 2006


Ekkehard Gümbel schrieb:
> Martin Kutschker schrieb:
> 
>> Ok, how about this:
>>
>> "1": send headers that allow public caching (current)
>> "public": same as 1, but makes clear what is sent
>> "private": send headers that allow only private caching
>> "no-cache": send headers that disables caching
>>
> Hmm... I am afraid that will lead to even more confusion.
> Basically, sendCacheHeaders is set to enable cache-related HTTP headers 

And my suggested options do not reflect this? I have no problem naming them 
"proxy" and "browser" for those who are not familiar with HTTP.

> - in most cases to make proxy caching possible in the first place.
> To date, this includes surpressing proxy caching for specific pages.
> Thus the decision between what you call "public" and "private" is the 
> one that TYPO3 already makes internally.
> 
> Surpressing client-side ("private") caching is a quite different matter 
> and may be interesting even if there is no proxy caching around.

Then I don't seem to understand what you are tyring to achieve.

>  > So we have backwards compatibilty and full control.
> Actually, cache-related headers do not give much control anyway since 
> the behaviour of all those proxies and browsers out there vary widely.
> 
> To me, different cases are:
> - I want to allow proxy caching for cachable pages

IMHO "public" implies "private" so it's basically it means "allow caching". 
  "public" is only broader in scope than "private". But that's what is done 
right now with sendCacheHeader, right?

This is option 1/public/proxy

> - I want to allow proxy caching for cachable pages and to surpress 
> browser caching for everything else

Same logic as usual but a forced "no-cache" instead of Ole Tange's 
"private", right?

This is option private/browser

> - I want to surpress any caching (i.e. both proxy and browser) for all 
> pages
> (Since the internal "cachable pages" decision is already quite 
> sophisticated, to me the latter point is not so important.)

Won't hurt.

This is option no-cache

So I don't see what's wrong with my config proposal. If the page is not 
cachable TYPO3 shall send no-cache in any case, but if it's cachable apply 
logic as requested by sendCacheHeaders.

Masi




More information about the TYPO3-dev mailing list