Not a bug Images attached in webp format are not cached

M

Mike S

Member
Affected version
2.3.0 Release Candidate 3
Hello.

Images attached in webp format are not cached.

Is there a reason?

Resumen
URL: https://xenforo.com/community/attachments/1714198860968-webp.301915/
Estado: 200
Origen: Red
Dirección: 172.67.1.248:443
Iniciador:
photo-of-the-day-potd.221244:2294

Respuesta
:status: 200
Cache-Control: private, no-cache, max-age=0
cf-cache-status: DYNAMIC
cf-ray: 893bc836df2a1bc1-MAD
Content-Disposition: inline; filename="1714198860968.webp"
Content-Length: 153924
Content-Type: image/webp
Date: Fri, 14 Jun 2024 16:43:55 GMT
ETag: "1714198861"
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Last-Modified: Fri, 14 Jun 2024 16:43:55 GMT
Server: cloudflare
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
 
From my understanding, this has always been the case with XenForo attachments out of the box. Mostly because attachments have permissions and guests might not have access to them.

Mike

XF 2.2 Post in thread 'Disabling Xenforo's cache-control header for better caching?'

This isn't fundamentally changed from XF1. Notably, we have always sent the cache control as private which means any shared cache (reverse proxy, Varnish, etc) should absolutely not be saving the output as it is user/request specific. Even in the case of guests that are request-specific values (notably, the CSRF protection).

If you wanted to do some sort of caching outside of XF, you'd need to apply bypasses based on cookies that might indicate the presence of a logged in user or a situation that is using custom things for guests and potentially explicitly white list certain paths so that...
 
Yeah, we set ETag and return 304 for requests with a valid If-None-Match header, but otherwise these are necessary to prevent shared caches from caching attachments, which would bypass permission checks. This applies to all attachments, not just .webp ones.
 
Back
Top Bottom