Caching no matter what

[caftpx10]

The problem I'm having since adding a new domain the Cloudflare-way is that my CSS file is strongly cached and the updated version of the CSS file will not be retrieved until around 10 minutes to an hour. I've tried turning on development mode on, paused Cloudflare, purging the cache, all the usual (be aware that this didn't happen before). I've then tried "disabling" varnish cache just in case that was the cause but it didn't help at all.

I've sent a ticket to Cloudflare regarding this caching over 24 hours ago and they've not replied as of yet.

This issue is pretty irritating as I'm trying to style a single UI element to look good but it's either too big or small after a few minutes and therefore I cannot easily get the correct size.

 

[essellar]

The only good way to do it is to version your static files when they need to change. When you change the content of a file that would ordinarily be treated as static (CSS, images, any JS obtained via GET with no query string), you have to depend on every single element in the chain (user agent, ISP caches, CDNs and your server) getting the "must update" message, and if that wasn't in the header of your original file, they may not. When you change the file name, you immediately invalid all caches globally (assuming, of course, that the HTML you're serving isn't cached).

 

[caftpx10]

I've tried the GET trick (with query string) with the caching for static files using GET turned off and on development mode, this however did not make a change.
I've just commented in a version within the CSS file just to make checks easier.

Renaming could help but it uses a lot of time just to change a bit. I'll try that later on.

 

[caftpx10]

I've got a reply from Cloudflare support and according to them, varnish is the cause of this even though I thought I've prevented this using the suggested method in the forums.

 

[essellar]

Resource file renaming is normal. Ordinary. Standard operating procedure. Should be a single global change, unless you are hand-coding static HTML pages, not "too much work". As I said, it's the only sure-fire way around user agent and ISP caches, since cached instances will have the "please cache me" header in place, and a new request to check the cache header on the version on the server will never be made until the item ages out.

 

[caftpx10]

Ok. All of my content on my site is fully hand-coded using dynamic content (obviously not the image).
As this seems to be caused by varnish (which looks like is misbehaving since the change), I'm wondering if there's an other way of preventing it from taking effect, to make it easier to update the site, as I've said this never happened before.

 

[caftpx10]

Oh, and here's the reply:

Hello, thank you for contacting CloudFlare.

curl_direct ancode.uk/css/styles.css
X-Varnish: 190879918
Via: 1.1 varnish-v4
X-Cache: MISS
CF-Cache-Status: HIT

When checking on the server, I am seeing varnish appearing to cache

./curl_resource ancode.uk 198.91.81.4/css/styles.css
HTTP/1.1 200 OK
Date: Tue, 16 Dec 2014 00:28:42 GMT
Server: Apache
Last-Modified: Mon, 15 Dec 2014 20:24:09 GMT
Vary: Accept-Encoding
Cache-Control: public
Expires: Tue, 23 Dec 2014 00:28:42 GMT
Content-Type: text/css
X-Varnish: 182251521 190879919
Age: 197
Via: 1.1 varnish-v4
X-Cache: HIT
X-Cache-Hits: 1
Transfer-Encoding: chunked

 

[Corey]

Add this to your .htaccess file in or below the directory that is having the caching issue:

Header set Cache-Control "max-age=0, private, no-cache, no-store, must-revalidate"

 

[caftpx10]

Add this to your .htaccess file in or below the directory that is having the caching issue:

Header set Cache-Control "max-age=0, private, no-cache, no-store, must-revalidate"

I've tried this before and now have tried this again exactly how typed (even though it is pretty much the same) but it resulted in the same thing.
Maybe I have to try placing this in a PHP header?

 

[essellar]

That idea won't affect your static files, unfortunately. You should be bypassing the Varnish cache (and anything else that obeys the cache-control header) once your original, cached files have aged out of cache. Varnish should be getting the message quickly with that .htaccess directive, but that won't have any effect on anything else in the cache chain (between the user and Varnish — browser cache, ISP caches, etc.).

 

[caftpx10]

That idea won't affect your static files, unfortunately. You should be bypassing the Varnish cache (and anything else that obeys the cache-control header) once your original, cached files have aged out of cache. Varnish should be getting the message quickly with that .htaccess directive, but that won't have any effect on anything else in the cache chain (between the user and Varnish — browser cache, ISP caches, etc.).

I do have other things in .htaccess that compresses and caches the files after that header but there are no other headers apart from that. Even if that was the case, this issue didn't occur before.
I'm not so sure if this is to do with my add-on domain being swapped around. I did not test the caching while adding an other domain and setting it up with Cloudflare.
Since Varnish is still taking effect and you've mentioned about aging out cache, I was wondering how long the cache expiration would be.

Will I need to re-setup the domain and Cloudflare for this to be working as normal again?

 

[p337x10h]

I had this problem with some javascript I was running, it was really frustrating.
This is probably highly unconventional, and not recommended. (i host a personal website)

I used inline Javascript (CSS would work the same as well), and then incuded it in its own PHP file, and referenced it with the require_once() statement, so it acted like inline javascript, but I was still able to centrally manage the content in its own php file.

You may not be using php however. and your site is probably much more professional than mine
but thats how I worked around this issue. it was by putting it inline (please note again: not recommended)

But I guess if you get super (ultra) desperate this info may be helpfull.

 

[caftpx10]

I had this problem with some javascript I was running, it was really frustrating.
This is probably highly unconventional, and not recommended. (i host a personal website)

I used inline Javascript (CSS would work the same as well), and then incuded it in its own PHP file, and referenced it with the require_once() statement, so it acted like inline javascript, but I was still able to centrally manage the content in its own php file.

You may not be using php however. and your site is probably much more professional than mine
but thats how I worked around this issue. it was by putting it inline (please note again: not recommended)

But I guess if you get super (ultra) desperate this info may be helpfull.

That's actually a good idea, I'll consider this as an option if this can't get sorted out (which it should).
As it's including the actual file and not just masking, I would have to add style tags. As always, there's a downside like that Cloudflare won't be able to cache the newer files as the browser is not requesting them but rather than the actual server placing file content into a request.

From the sounds of it, it's affecting a few users but the questions are why and how?