During site development I will frequently have to remind the client to refresh their browser (F5) to clear their browser cache and see the new version of the site page. Once the site is live and I switch on Couch caching in config.php how does server caching interact with browser caching? If a page's content changes Couch will delete the cached version and serve the new version ... would this somehow override the client's browser cache?

[KK]

Couch's caching is totally independent of browser's caching.
The browser will never know if it is being served a cached page or a dynamically generated page by the web server.
So the 'refresh using F5' part remains the same whether or not you choose to deploy Couch's caching.

The way Couch's caching works, anytime you hit the 'save' button on any of your pages in the admin-panel, the cache gets invalidated (destroyed in a sense) and all further requests are fulfilled by dynamic generation (of course, with the output getting cached so another request for the same page is handed over the cached output).

Does this answer your query? Please let me know if something is unclear.
Thanks.

[cheesypoof]

No pages are cached by the client's browser in the first place. An F5 refresh that clears the browser's cache therefore is not necessary after saving a page in Couch. You simply need to visit the page again to see the changed content generated.

An easy way to understand what is going on when you visit a page is to enable your browser's web console and see all of the HTTP requests being made.

No pages are cached by the client's browser in the first place.

Could you explain that please cheesypoof ... how can we know what is cached or not cached by a client's browser?

Yes I'll have a look at some http requests - perhaps that will clarify everything.

[cheesypoof]

HTML is always changing to reflect new content, so in most circumstances it is not static. Browsers therefore will not cache it by default as they don't want to risk serving stale content.

You can tell if a resource is being served from your browser cache if no HTTP request is made to download it from the server.

To ensure consistent behavior across all browsers, you should configure caching in your root htaccess file. This is one way to do it for images, js, and css:

Code: Select all

<IfModule mod_expires.c>
ExpiresActive on
ExpiresDefault "access plus 0 seconds"
ExpiresByType text/css "access plus 4 weeks"
ExpiresByType image/gif "access plus 2 months"
ExpiresByType image/png "access plus 2 months"
ExpiresByType image/jpeg "access plus 2 months"
ExpiresByType application/x-javascript "access plus 3 months"
ExpiresByType application/javascript "access plus 3 months"
ExpiresByType text/javascript "access plus 3 months"
<IfModule mod_headers.c>
Header append Cache-Control "public"
</IfModule>
</IfModule>

You can always change any of the times to your liking.

http-request.png (26.56 KiB) Viewed 7665 times

You can see the cache instructions being sent to the browser as part of the 'Response Headers' under 'Cache-Control'. This is from Firefox by the way.

You may also want to read https://developers.google.com/speed/docs/best-practices/caching

[KK]

@cheesypoof

HTML is always changing to reflect new content, so in most circumstances it is not static. Browsers therefore will not cache it by default as they don't want to risk serving stale content.

I agree this is how browsers are supposed to behave (and most of the time they do behave like this) however a very recent happening served to shake my belief in this axiom.

I was contacted by a client with a problem that I had never encountered before - any time he made any changes to the pages in the admin-panel, he had to use F5 to refresh for the changes to appear in the admin-panel!
Create a new dynamic-folder and the folder won't appear in the list until F5 was hit. Add images to portfolio and the same thing there. It was really a frustrating experience.
The intriguing thing was that *all* the browsers on his machine were displaying the same problem (he send me a video clip) while when I accessed the admin-panel from my machine everything seemed ok.

Clearly (for reasons still not understood by me - maybe there was a proxy somewhere in the chain) the browsers on his machine were caching HTML too aggressively - to the extent that they never requested the web server for any page that had been accessed before.

I rectified the problem by making the web-server explicitly send instructions to the browsers absolutely not to cache at all (not even once) any of the admin-panel pages.
This is how I did it (might come useful to someone) -
Edit the 'couch/config.php' file and add the following lines at the very end of it

Code: Select all

if( defined('K_ADMIN') ){
   // HTTP headers for no cache
   header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
   header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
   header("Cache-Control: no-store, no-cache, must-revalidate");
   header("Cache-Control: post-check=0, pre-check=0", false);
   header("Pragma: no-cache");
}

I am not sure if it'd be a good idea but if necessary the same instructions could be given for the normal front-end pages too (by removing the 'if' condition). The client will never have to hit F5 again as the browser will always request the web server for all pages. The caching part could be handled completely by the server alone.

... suspicions confirmed - I am a geek (or at least a semi-geek) ... this is all really interesting stuff - thanks cheesypoof for posting such a detailed and helpful response and kk for the tale of browser cache woe from a client. Just goes to show what a complex world we are operating in ... I'm going to follow up on all of this and get a better grip of it all.

[cheesypoof]

@KK
That's quite an odd scenario. Good to know for the future.

@potato
No problem.