staticfilecache

staticfilecache copied to clipboard

Bug Report

Current Behavior

• create empty page
• Insert a content element on that page.
• Set starttime to 5min in future
• Visit FE in different browser or inkognito mode: blank page
  • check iexpire-header in network tab: it shows a datetime that is 5min in future
• check in staticfilecache backend module:
  • page cached: yes
  • page created: now
  • page expiry: in 5 mins
• check filesystem: folder with .htaccess, index.config.json, index.gz is there

Now we wait 5mins to reach starttime.

Now we visit the staticfilecache backend module:

• it shows: No entries on this level of the page tree. -> fine

Now check filesystem:

• `folder with .htaccess, index.config.json, index.gz is still there -> bad

Now visit FE:

• you still do not see the CE which should be visible by now.

Expected behavior/output

folder with .htaccess, index.config.json, index.gz should be gone/deleted along with page cache

FE:

• you see the CE

Environment

• TYPO3 version(s): 10.4.15
• staticfilecache version: 12.1.0
• Is your TYPO3 installation set up with Composer (Composer Mode): yes
• OS: Linux

Possible Solution

delete expired files in filesystem

Additional context Add any other context about the problem here

Do you saw this option in your generated htaccess files: https://github.com/lochmueller/staticfilecache/blob/master/Resources/Private/Templates/Htaccess.html#L9

This rule should redirect to TYPO3 again after the end of the cache entry and TYPO3 should regenerate the page. An alternative is the Garbage Collation Scheduler task.

Regards, Tim

Hmm... the problem is, that the hatccess file in the cache folders are not loaded (don't know why). You see this also in the response headers (missing x-sfc-tags & x-sfc-state headers). If you call the website the headers are missing. If you call directly the cache file (normally prevented by htaccess), the right headers are added.

HTTP/2 200 
cache-control: max-age=86062
content-language: de
content-type: text/html; charset=utf-8
date: Fri, 28 May 2021 07:59:21 GMT
expires: Sat, 29 May 2021 07:53:43 GMT
pragma: public
server: Apache/2.4.38 (Debian)
vary: X-Forwarded-Proto,X-Forwarded-Port
x-content-type-options: nosniff
x-powered-by: PHP/7.4.16
x-ua-compatible: IE=edge
content-length: 16616



curl --head https://t3m.lndo.site/typo3temp/tx_staticfilecache/https_t3m.lndo.site_443/index

HTTP/2 200 
accept-ranges: bytes
cache-control: max-age=86142
content-language: de
content-type: text/html; charset=utf-8
date: Fri, 28 May 2021 07:59:37 GMT
expires: Sat, 29 May 2021 07:55:20 GMT
last-modified: Fri, 28 May 2021 07:55:20 GMT
server: Apache/2.4.38 (Debian)
vary: Accept-Encoding
x-content-type-options: nosniff
x-sfc-state: StaticFileCache - via htaccess
x-sfc-tags: pageId_1
x-ua-compatible: IE=edge
content-length: 16409```

@infabo So currently this works only with the garbage collection. The backend module display valid cache entries. So it is possible that there is a DB entry and files in the cache, but you do not see this in the backend module. So please add the "Garbage collection" task for the StaticFileCache backend in the scheduler, to solve this problem in short term.

Thanks! Sorry for not responding in time. I checked after your reply 16 days ago and the sendCacheControlHeaderRedirectAfterCacheTimeout kind of worked. It still was kind of weird acting (as it did not refresh immediately but after some minutes the page expired). Seems like as you already pointed out now, that garbage-collection is the only reliable approach/solution right now.

I will close this issue. The solution is the sendCacheControlHeaderRedirectAfterCacheTimeout and/or the garbage collection tasks of the caching framework.