Cache Control Header Not Sticking

ok, seems like this doesn’t work when i have a page cache plugin active (cache-enabler plugin). So i disabled the plugin and used litespeed server cache.

I now have 2 headers, is this correct? One is the header i set with this plugin, and the other is what i set in htaccess for expires caching:

cache-control:max-age=31104000 (set with this plugin)
cache-control:public, max-age=2592000 (what i set in htaccess expires caching)

I can remove the 2nd header by removing the following from htaccess
ExpiresByType text/html “access plus 1 month”

Hi,

The Cache-Control plugin for WordPress works with any other plugin, cache, accelerator, proxy, or other infrastructure that speaks and support standard HTTP. The plugin you were using obviously didn’t support HTTP as it didn’t preserve the headers.

You can have as many Cache-Control HTTP response headers as you want. The lowest max-age value takes precedence. Having multiple headers may confuse some more simpleminded clients, however. Please note that the public directive is unnecessarily (the default).

Hi, yeah, i’ve got this working well with the litespeed cache now so that’s good. Was using the keycdn cache-enabler plugin and also simple-cache plugin and both stripped your headers.

As for the cache-control, if i have the following in htaccess is it correct that this instructs both the browser and the cdn how long to preserve the cache?

	<filesMatch "\.(ico|jpg|jpeg|png|gif|webp|swf)$">
        Header set Cache-Control "max-age=31536000"
    </filesMatch>
    <filesMatch "\.(css)$">
        Header set Cache-Control "max-age=31536000"
    </filesMatch>
    <filesMatch "\.(js)$">
        Header set Cache-Control "max-age=2592000"
    </filesMatch>
    <filesMatch "\.(woff|woff2|ttf|svg|eot|otf)$">
        Header set Cache-Control "max-age=31536000"
    </filesMatch>

In which case, is it necessary to also include expiresbytype directives in the htaccess as such? (This is just an example, the actual expiry values would normally match those of the cache control)

ExpiresActive On
ExpiresByType text/html "access plus 1 day"
ExpiresByType image/gif "access plus 1 years"
ExpiresByType image/jpeg "access plus 1 years"
ExpiresByType image/png "access plus 1 years"
ExpiresByType text/css "access plus 1 years"
ExpiresByType text/javascript "access plus 1 years"
ExpiresByType application/x-javascript "access plus 1 years"
ExpiresByType application/javascript "access plus 1 years"

I removed the expiresbytype and just kept the cache control and pagespeed didn’t give me any warning about browser caching.

Is there any reason to keep both expiresbytype and cache-control? Or do you recommend just using cache-control?

Cache-Control is easier to implement, and introducing the legacy Expires header just adds ambiguity. Stick with Cache-Control. If you or any of your users depend on any legacy software that only support HTTP/1.0 then you may want to add back the Expires header. However, there shouldn’t be any humans left using that protocol version. It may affect some bots and scripts still, but nothing to worry about.

That’s great to hear, from what i researched cache-control was released after expires and so take precedence over it should both be present.

As you seem to be quite knowledge about caching, i was wondering what your opinion is on ETags?

Some people say it’s best to remove them, while others state that removing them can be harmful for caching, especially if you’re using a cdn.

I’ve currently enabled them in htaccess using “FileETag MTime Size” as i’m also using a cdn. What i can’t figure out though, is why gtmetrix keeps telling me my etags are misconfigured. I thought i had the correct implementation for cdn use. Is gtmetrix correct?