Pushing New File Version without Hard Reload

The problems will most likely happen, when the user is not aware the need of loading files from fresh with "Hard Refresh" or the users are not aware about differences between "soft" and "hard" refresh versions at all.

Headers on .htaccess

The first obvious solution would be using header information on all files by particular type, defined in .htaccess on server side:

<IfModule mod_headers.c>
 <FilesMatch ".(json|pdf|swf|bmp|GIF|JPEG|JPG|PNG|gif|jpeg|jpg|png|svg|tiff|ico|flv|js|php)$">
  ExpiresActive On
  ExpiresDefault "access plus 1 week"
  ExpiresByType application/pdf "access plus 12 hours"
  Header append Cache-Control "public"
 </FilesMatch>
</IfModule>

All other defined file types have expiration time 1 week, but "application/pdf" has it set shorter, only 12 hours.

However, it seems defining some particular file types, for example .pdf separately, may not work very well. At least during testing, the Google Chrome still displayed the older version of uploaded file.

Using Versioning on File Name

If there is the imminent need for serving newest version of file to the user, one solution is to modify the ending of file name by adding version number.

<a href="/s2/760_643_73_Agenda_of_Seminar.pdf?version=1.2" title="Download File">

<img src="js/icons/pdf.gif"> Agenda of Seminar (.pdf 0,4Mb)

</a>

Adding different version number to the end of file as ?version=1.2 seems to work and forces Google Chrome to reload new file version every time, when version number is changed. Very important on that is, that there is no need on user side to use reloading (any combination) any more.

More Automated Version

If the link to the file is fully edited on content management system, described method may be used. However, it may be not very convinient to change file fersion by hand each time, the new file is uploaded. It may be also more difficult, when link to the file is created dynamically in content management system or the users are not aware of need to modify the version number.

One possible solution would be using automatic time stamp on php script using integrated function date() with format ddhhmmss as described on php manual.

in this way there is needed just to add date('dHis') to the end of file

$original_filename = '34_file.pdf';
echo "<a href='$original_filename?version=".date("dHis")."'>
Download the file
</a>";

It prints current time to the end of each time, when page is reloaded and browser loads the file again on every pageview. However, this is against of real purpose of buffering static file types as .pdf is.

More Optimized Way

To avoid loading file again each time, you may store last update time to database and then print new version number based on that to the end of file. Then the link to the resource differs only, when there is new uploaded version of particular file.

$original_filename = '34_file.pdf';
$original_timestamp = $sql[file_saving_date];
echo "<a href='$original_filename?version=".date("dHis", $original_timestamp)."'>
Download the file
</a>";

In this way the old name may be in buffer as long as there is no new version uploaded to the website throught content management system.

Why there is Hard Refresh Anyway?

It seems, that Google would like to have more diversification on dynamic and static resources for their indexing systems. For example, those picture files and documents, which are remaining same for very long time, downloading the file each time is waste of resources, when the file is essentially same all the time.

Difersifying "Refresh" and "Hard Refresh" makes more clear how dynamic and static resources are treated by Google and gives hint to serve those files, which actually change in more "dynamic" fashion, so they will be indexed and displayed from updated source.