[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