The problem:
With cache control is setup in .htaccess and when a "304 Not modified" response header status code is returned (through surfing between web pages), an Etag directive should be included in the response header. But it isn't: the Etag directive is missing.
This is a problem with respect to using Litespeed to effect the behaviour (through response headers) of a browser's cache. That is, it is not a problem of caching on the (Litespeed) server itself.
Steps to reproduce the problem:
[My production site www.philorum.org currently set up with the relevant .htaccess cache control for http://www.philorum.org/index.html. But I provide all the relevant steps to reproduce if you visit this thread in the distant future.]
Expected:
Notes:
Edit: Simplified "Expected" description.
With cache control is setup in .htaccess and when a "304 Not modified" response header status code is returned (through surfing between web pages), an Etag directive should be included in the response header. But it isn't: the Etag directive is missing.
This is a problem with respect to using Litespeed to effect the behaviour (through response headers) of a browser's cache. That is, it is not a problem of caching on the (Litespeed) server itself.
Steps to reproduce the problem:
[My production site www.philorum.org currently set up with the relevant .htaccess cache control for http://www.philorum.org/index.html. But I provide all the relevant steps to reproduce if you visit this thread in the distant future.]
- htaccess with cache-control set to: always validate browser cached version against server representation.
# --------------------------------------------------
# Etag Header
# --------------------------------------------------
# Include here as some Web Hosts have turned off Etags by default.
# Don't use INode as part of the Etag as that will falsely flag a changed document
# when a file is served from any of several servers (in a cluster)
# http://httpd.apache.org/docs/2.4/mod/core.html#fileetag
FileETag -INode +Size +MTime
# --------------------------------------------------
# Browser Caching Rule
# --------------------------------------------------
# Files (here just the home page, index) ought always be checked with the
# server to see if the local copy is different from the server copy.
# That is, always validate.
<FilesMatch "^(index)\..+$">
Header set Cache-Control "max-age=0, public"
</FilesMatch> - In Firefox ...
- Surf to http://www.philorum.org/index.html. Press F12 for developer tools > Network Tab. Click "reload" in developer tools Network tab.
- Ctrl + F5 for a forced retrieval of files from the server. In Developer Tools > Network > Click on the index.html record > Headers [Tab]
- Observe Status Code "200 OK" and, in the reponse header, (something like) Etag: ""19ac-5618a670-0"". This all looks good so far.
- On the webpage http://www.philorum.org/index.html click on "Draft Constitution" link, to surf away from index.html.
- Click on "Home" to surf back http://www.philorum.org/index.html . Observe, in Developer Tools > Network > Index.html > Headers .... Status Code "304 Not Modified" and, in the response header, no Etag.
Expected:
- 7. Status Code "304 Not Modified" and, in the response header, an Etag (with a value identical to the previously cached Etag, to assert that index.html has not been modified).
Notes:
- This is identified at https://redbot.org/?uri=http://www.philorum.org when mousing over the warnings for "The If-None-Match response is missing required headers" and "The If-Modified-Since response is missing required headers" there is information about the missing Etag.
- This problem occurs whether the web pages are compressed (gzip) or not compressed.
- In firefox (at least) a "304 not modified" response correctly does not come with a message payload (the full webpage) - it is taken from the cache. This is ultimately what the "304 not modified" response status code is for ... so the caching *is* behaving as expected and desired - however without the Etag as is required. (So the caching works as desired but by luck rather than design).
- I'm new to Litespeed and don't have a local development copy. The site above, www.philorum.org, is served from a third party commercial web host which uses Litespeed (as is evidenced in the response headers). In short, it's entirely possible I'm missing something basic.
Edit: Simplified "Expected" description.
Last edited: