[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