{"id":39538,"date":"2018-07-18T03:01:42","date_gmt":"2018-07-17T17:01:42","guid":{"rendered":"http:\/\/www.rjmprogramming.com.au\/ITblog\/?p=39538"},"modified":"2018-07-17T15:46:20","modified_gmt":"2018-07-17T05:46:20","slug":"php-webpage-expiry-and-the-cache-primer-tutorial","status":"publish","type":"post","link":"https:\/\/www.rjmprogramming.com.au\/ITblog\/php-webpage-expiry-and-the-cache-primer-tutorial\/","title":{"rendered":"PHP Webpage Expiry and the Cache Primer Tutorial"},"content":{"rendered":"
\"PHP<\/a>

PHP Webpage Expiry and the Cache Primer Tutorial<\/p><\/div>\n

We wanted to talk about the serverside (ie. PHP, for us) topic of Webpage Expiry, for web applications. You will probably know, if you surf the net, go to a webpage, do some other work, and go back to that original webpage in the same way, you may get identical content even though you know for a fact that that content, should be different and updated. That can be either a weakness at that website’s web server code, or be an approach to speeding up response times for the user by using the web browser’s cache<\/i><\/a> to save on revisiting web servers constantly, to get content.<\/p>\n

The topic of “Webpage Expiry” involves the setting at the web server (for us at www.rjmprogramming.com.au, using PHP) of the webpage’s expiry date\/time, via the manipulation of the HTTP Expires<\/i> header. While the Webpage is “current” the cache will be called into play, but as soon as the Webpage HTTP Expires<\/i> header is “clicked over” timewise, a “rereading of content from the web server” (or “refreshing the cache”) is triggered. With today’s proof of concept self_destruct.php<\/a>‘s live run<\/a> we’d like to thank …<\/p>\n