Client receives 304 header unless manifest files are changed

[Peut]

The ClientCacheFilter retrieves the modified date of the manifest file, and compares it to the Last-Modified header. However, if the content of any file that is referenced through the manifest file is changed, his still results in a 304 reply. Even though the actual contents of the file is altered.

This causes problems on our website, because our javascripts / stylesheets will change regularly but our manifest files do not.

Our current solution is to 'touch' every manifest file when updating our production server, so all clients receive the new scripts and stylesheets. This is however not an ideal situation for us, and we think that other users of this package would benefit from an integrated solution.

Perhaps it is an option to store the last-modified date internally, updating its value when running the assets:clean command?

[mcblum]

Have you tried running php artisan assets:clean?

[Peut]

Yes, 'php artisan assets:clean' is part of our deployment script and runs on every update. This does successfully remove the cached files on the server, but it does not have any effect on the timestamp of the manifest files which are used for cache-control to invalidate the client cache.

So even though the server cache files have been removed, the client will still receive a 304 header indicating that the client cache is still valid.

[mcblum]

@Peut Any idea why of all of the files in our app the only ones that will not, under any circumstances, show a 304 response code are application.js and application.css? It's driving me crazy :)