[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