Purge cache on file change

[nilshoerrmann]

It often happens that clients update images in the backend: similar but edited file, same name, but different. JIT doesn't notice this change and still serves the outdated cache file.

I know that using a different name circumvents this issues but I'd expect JIT to purge the cache for a file when it is edited or deleted by Symphony.

[michael-e]

Even if JIT created a new cache file, the client (browser) would still obey the cache headers of the old file. You can not "unset" the cache headers of a file which has already been delivered to a client. In order to ensure that the client actually requests the new file, you either need a new name (e.g. with the Unique Upload Field) or the cache for your files set to 0 set all response headers of your files so that they are never cached (not recommended).

[nilshoerrmann]

Well, yes, but what you describe is a secondary issue that can be solved by clearing the browser cache.
The current JIT behaviour results in incorrectly served images even for first time users because the image cache on the server is not updated when the source file changes.

The extension adds the original file name to the cache file name – e. g. 712fc16f4035f77e304e3fd97b5c0d0d_logo_foerdererkreis-hbk.png – so it shouldn't be too hard to remove the related cache files.

[michael-e]

Have you ever seen a user clearing the browser cache?

You are right when you say that it is incorrect resp. unexpected behaviour, but I think that a fix would introduce complexity while being pointless at the end of the day. You might prove me wrong. :-)

[nilshoerrmann]

Have you ever seen a user clearing the browser cache?

Yes, actually I've seen it many times. We actually have clients telling us that they cleared the cache before we instructed them to do so.

You are right when you say that it is incorrect resp. unexpected behaviour

It's not unexpected behaviour. The served file is simply wrong. That's a bug, not a personal taste :)

[nilshoerrmann]

For reference, Cacheable Data Source clears the related cache on save.

[michael-e]

We actually have clients telling us that they cleared the cache

I meant "all the other users", not clients. Or does your website contain a warning like "please drop your cache every time you request a page" (which wouldn't help with proxies anyway).

The served file is simply wrong.

One might debate that. If you identify a resource using a URI/URL, are you really "technically allowed" to change that resource to your liking? A newer version of a person's portrait? No prob. A completely different image with same meaning? Sounds reasonable. But a different image with completely different content/message? Are you sure that this is the intention of the URI/URL concept? :-)

Anyway. Let's assume that JIT delivers "the wrong file" (because someone replaced the original file). So what? It won't help to serve the right file unless you can live with the caches in browsers (and proxies alike). Do you know your cache headers?

If JIT serves a new file, you will see the correct image when you clear your browser cache. Now will you believe that you solved the problem? How funny. Many of your visitors out there will see the old image for a week or so (depending on your cache headers). And this means: Serving the right file has led you to the wrong track. You are even fooling your client/authors, because you make them think that they solved the problem by clearing their browser's cache.

"Fixing" JIT's behaviour does not solve your problem.

[nilshoerrmann]

"Fixing" JIT's behaviour does not solve your problem.

It does. Serving the correct image from the server.

I'm never in control of what the site visitor sees – there is the browser cache, there are network connectivity issues and such. I'm aware of all this. But I have control over my server, and my server is serving something wrong. If I "know my cache headers" has nothing to do with this at all.

One might debate that. If you identify a resource using a URI/URL, are you really "technically allowed" to change that resource to your liking? A newer version of a person's portrait? No prob. A completely different image with same meaning? Sounds reasonable. But a different image with completely different content/message? Are you sure that this is the intention of the URI/URL concept? :-)

This as well is a discussion worth to pursue, but it has nothing to do with the case made in this issue: If the user changes an image for whatever reason, even if you don't approve it, the server is not reacting correctly.

Sorry, Michael :)

[nitriques]

If you identify a resource using a URI/URL, are you really "technically allowed" to change that resource to your liking?

No, you are not if you want to adhere to the spec!

If the user changes an image for whatever reason, even if you don't approve it, the server is not reacting correctly.

But that's the reality: the user did change it. Try to make your client understand a spec is way to much for them.

My proposition is this: If the filemtime of the original file is later than the cache, do not send/use the cache.

This does not require magic on save and should cover most cases. I won't go into invalidating proxies cache, as this is too complex. But at least, jit would send the correct thing, http headers included so any request won't respond with a 304 with with a 200.

[michael-e]

My proposition is this: If the filemtime of the original file is later than the cache, do not send/use the cache.

So the cache would no longer be used for this image?

[nitriques]

@michael-e exactly: it would even get overwritten since we would act as if it did not exists.

[michael-e]

So a new cache file would be written? Sounds good.

[nilshoerrmann]

My proposition is this: If the filemtime of the original file is later than the cache, do not send/use the cache.

I like that idea.