[TYPO3-dev] Cache-Control Headers
Martin Wagner
martin.wagner at iue.tuwien.ac.at
Wed Aug 22 14:54:48 CEST 2012
Hi list,
I'm currently struggling with a TYPO3 installation specifically providing a fe-user login section. A customer sitting behind a company proxy had issues correctly displaying a user-logged-in-only page, what lead me to investigate the issue a bit closer. By default, TYPO3 sends the following headers:
Cache-Control: no-cache, must-revalidate, public
Pragma: no-cache
For the page with the login form, I get
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0, public
When logged in as a FE user, I get for a page accessible only for this user(group) the same as a normal page
Cache-Control: no-cache, must-revalidate, public
which is not the best option, I think, because if I restrict a page it should also be set to private in the cache-control header, or am I wrong at this point?
In order to tackle that problem, I tried two things, both leading to similar results:
.) setting config.sendCacheHeaders = 1
Cache-Control: private, public
what looks to me as a contradiction in terms...
.) setting config.additionalHeaders = Cache-Control: no-store, no-cache, private
leads to
Cache-Control: no-store, no-cache, private, public
which is, in principle, the same behavior as above. I checked the W3 document on this, which you can find at http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html. Section 14.9 depicts the information on the Cache-Control Headers, but does not depict any standard behavior for funny combination of attributes. Can I get sure that everything is alright for my FE-user area or shouldn't be the default behavior of TYPO3 adapted in order to avoid the private, public combination?
Best,
Martin Wagner
More information about the TYPO3-dev
mailing list