How is browser caching handled

Resolved fjhughes
(@fjhughes)

2 years, 6 months ago

I have had users report publishing a document, then updating it, but then on the front end, the site visitors gets the previous version. Is that a bug, or is there a setting to handle that? Also, what if a CDN is in place, how would caching be handled in that case?

Viewing 5 replies - 1 through 5 (of 5 total)

Plugin Contributor nwjames
(@nwjames)

2 years, 6 months ago

@fjhughes,
When you enter a URL pointing to the latest version of the document, it will change that URL into a query and find the document post_type record that relates to the query. It will point to an attachment post_type. This attachment, in turn, links to the document file. The name of this file is an encoded form of the actual document name and the time that it was loaded though the interface.

This is a long-winded way of saying that when a user updates a document via the plugin, the update is to make the original post point to a different attachment and have a document that links to a different encodeed name.

So IF your users are aying that they are seeing the original document, then it must be that a caching process is acting so that the document is NOT retrieved.

When the document is served, it is served with two relevant headers ETag and Expires or Cache-Control.

ETag is generated from the last-modified date of the base document. If you have previously downloaded the document to your browser, and you ask for it again using this value, then the server can say that it should use the previous version by sending a 304 retuen code.

This will not be appicable the update has been made using the plug-in process since it will update the last-modified date of the post – and so this code will not be included.

Expires/Cache-Control on the other hand is used by the browser to determine whether to use the local version oe to ask the server for a new one.

Expires was used in Version 3.3.0 and earlier. It was set to 100000000 seconds from the time that the file was downloaded to the browser. This is just over to 3 years.

In Version 3.3.1 this was changed to use the Cache-control header with a max-age of 8000000 seconds, about 3 months.

A forthcoming version will enable this value to be filtered.

It is entirely possible for this to be creating the problem you raise. This will not be a new problem but will be visible in all versions.

There is a filter document_revisions_serve_file_headers available in delivered versions that can be used to modify the output headers – to remove this header.

As long as the Etag header is working properly, it is a relatively low-cost option to get confirmation that the locally cached version is still valid, i.e. have a much smaller max-age value.

A CDN, by its nature, can only exacerabate this issue.

Hope this is of use,
Neil James
Plugin Contributor nwjames
(@nwjames)

2 years, 6 months ago
@fjhughes,
I have been thinking further on this issue. Currently if there is an Expires or max-age header Directive resulting n a cached version expiring in the future (i.e. all versions of the plugin), then since the browser only has the URL to use, it will systematically serve the cached version – and not even ask if it has changed.

It needs to be told to validate the content rather than just serving it. This is done using the Cache-Control directive no-cache. In this case, of course, there is no need to define a max-age.

If you put the following code into your wp-content/mu-plugins directory then it will do as required:
```
<?php
/**
Description: Set Cache-control no-cache
Author: Neil W. James
**/

if ( ! function_exists('wpdr_modify_cacheing')) {
	function wpdr_modify_cacheing( $headers, $file )  {
		$headers['Cache-Control'] = 'no-cache';
		return $headers;
	}
	add_filter( 'document_revisions_serve_file_headers', 'wpdr_modify_cacheing', 10, 2 );
}
```
Referring to your comment on CDNs, they must respect this directive too; but the payload of the validation message is far lower than the document itself so their use should be beneficial.

Hope this helps,
Neil James
Thread Starter fjhughes
(@fjhughes)

2 years, 6 months ago

Hi Neil,

Thanks for the input. I just looked, I do not have a mu-plugins directory. If I were to create it, how should I name this file that I add this code to and how will WP Document Revisions know to use it for no-caching?

Thanks!

Neil James (lcyh78)
(@lcyh78)

2 years, 6 months ago

@fjhughes.
Sorry for being rather cryptic. mu-plugins is a provided WordPress capability.

It is a place where you can store code that always will be used (mu = Must Use).

Its only requirement is that the files within it can be read by WordPress. This should happen when you create the folder.

You create the file as a php file, i.e. you can be call it anything with a php extension – but to be specific, please call it wpdr_nocache.php

When WordPress runs, it executes all files in the directory with a .php extension – including this one.

How it works? The key to WordPress;s flexibility is with its actions and filters.m
The plugin contains code to prepare the headers to send with the response, The headets tell the browser what is the type of the file, how big it is, etc.

But just before outputting the,, it has this line
$headers = apply_filters( 'document_revisions_serve_file_headers', $headers, $file );

Which allows you to take the array of headers and manipulate them as in the code I supplied so slightly different headers are output.

Because it is a plugin filter, it can only affect the header of documents as they are being served.

To stop it being used, either delete the code, or change its file extension.

Hope this clarifies,
Neil James

Thread Starter fjhughes
(@fjhughes)

2 years, 6 months ago

Hi Neil,

Thank you for your quick response. Yes, this makes sense. I’ve seen the MU directory on other installations, I assume it gets created by certain plugins when required, but if not, as in this case, it’s not there. I’ll create it and create the wpdr_nocache.php file with your code and test it out. I appreciate your help.

Thanks!

Viewing 5 replies - 1 through 5 (of 5 total)

The topic ‘How is browser caching handled’ is closed to new replies.

Tags