Topic on Project:Support desk/Flow

We're using [[Media:Example.jpg]] to include versioned pdf files. New versions of the file are uploaded via "Upload new file version" on the file description page.

After having uploaded a new file version, the browser keeps returning the old version until the browser cache is being flushed with "Ctrl+F5".

Question: Is there a way to ensure the newest file version is being displayed without having to hard refresh the page manually? Shouldn't mediawiki pass some kind of "expired flag" when a new file version is available?

Software	Version
MediaWiki	1.22.1
PHP	5.3.17 (apache2handler)
MySQL	5.5.33

Please upgrade your MediaWiki version and then get help.

There's no way to send an "expired flag" to the browser, because the browser is not requesting the URL to see if the file has been updated.

You should configure your server, the path that contains all your uploads, to send files with a Cache-Control: must-revalidate header, that will make the browser check every time if a new version of the file exists, and if not retrieve the cached version.

@Ciencia Al Poder, but 193.29.227.43's MediaWiki version is too old and need upgrading.

You already said that. I'm free to help people even if they use an unsupported MediaWiki version, specially if the problem is not with MediaWiki itself.

Thank you for your lucid explanation. I have asked our administrator to configure our server according to your recommendation and will then report the result here.

@Ciencia Al Poder, is this your extension:

https://github.com/ciencia/mediawiki-extensions-WikiDexFileRepository

Hi there,

I am experiencing the same issue.

I have to ask all users to manually purge the cache before opening a reupload of a file version.

Is there any other way to avoid this? I can edit all mediawiki files on the server, including .htaccess, but I don't have access to the server configuration.

Mediawiki Version 1.31.3

PHP Version 7.1.32

MariaDB Version 5.5.64-MariaDB

You may try setting a Cache-Control header in .htaccess with a short age and "must-revalidate", to cause browsers to check if a new version is available before returning the cached one:

# 10 minutes
Header set Cache-Control "max-age=600, must-revalidate"

See examples in https://www.askapache.com/htaccess/apache-speed-cache-control/

Thanks for the tip, I made this edit! I will follow up with my users in the next few weeks to see if it solved our problem.

I had the same issue and thanks to Science is Power @Ciencia Al Poder :-) guidance I was able to get this working for my instance in Windows Server 2012 R2 with IIS 8.5.

Make sure you have IIS 6 Scripting Tools and IIS 6 WMI Compatibility installed through Server Manager.

I basically opened IIS Manager and navigated to my website folder right clicked and selected "Add Virtual Directory". In the Alias field I put the same name as the folder in my case I customized wiki to use "uploads" folder so I put uploads in the field. For Physical path just hit the 3 dots and select your folder by navigating to it then hit OK.

Open command prompt as admin and enter the following commands please enter in your values in the bold words.

cd C:\inetpub\AdminScripts

cscript adsutil.vbs SET W3SVC/1/ROOT/YOUR WIKI SITE/YOUR UPLOAD_IMAGES FOLDER/CacheControlCustom "no-cache"

Then just test it out.

Note that disallowing browsers to cache images will cause a lot of more traffic to your server, and slowness on the wiki (because of the need to redonwload all images on every request).

It's better if you set the Cache-Control to "max-age=600, must-revalidate", (you can adjust the time) to allow images to be cached for 10 minutes, and then browsers will query the server to see if the image has changed, and if not, it will continue to use the cache without the need to download the image again.

Thanks for that info luckily my site is for a small group of folks but, I did notice that PHP's FastCGI process does eat up a bit of CPU when this happens and in my situation its not too bad.

If my site grows then I will most likely go down the max-age route.

One thing I wanted to add that upon more testing I figured out that by doing the CacheControlCustom to no-cache it messes with indexing the folder using Cirrus search where I can't search for any media that I added. So the max-age route is a better option to avoid messing Cirrus search.

I don't see how it can affect Cirrus Search, since Cirrus Search gets updated directly by MediaWiki (using php), whereas your CacheControlCustom property is applied directly to IIS and php is not involved at all. Your issue must be coming from somewhere else

Your right that was not messing with indexing I figured out that Cirrus Search takes a good amount of time to index so I need to try to figure out how to speed that up.

I keep having this bug with documents that I uploaded in my wiki. I already deactivated browser caching following this tutorial: https://techexpert.tips/apache/apache-disable-cache/

The issue is still persisting. Does anyone have another idea?

Wiki specs:

Product	Version
MediaWiki	1.31.10
PHP	7.2.24-0ubuntu0.18.04.7 (apache2handler)
MySQL	5.7.32-0ubuntu0.18.04.1
ICU	60.2

Your wiki is using an unsupported version and may be vulnerable.

Apart from that, check for any proxy or intermediate cache. If in doubt, append a random query string to the URL of the file to discard a problem with the file itself.

Thank you, I know the version is unsupported. Unfortunately I can not update the wiki at this point.

Adding a random query string brought no changes to the file.

I tried to find out about server side/intermediate caching. As far as I can tell there is no server side cache from the apache. In fact the cache modules are not active.. As for the cdn I am not really sure how to find out since I don't have access to the network architecture. I only have access to the docker the ubuntu server is running on.

running the URL of the File Page through https://redbot.org/ returned the following results:

HTTP/1.1 200 OK

Date: Tue, 21 Mar 2023 08:38:12 GMT

Content-Type: text/html; charset=UTF-8

Transfer-Encoding: chunked

Connection: keep-alive

CF-Ray: 7ab4e0928e129e70-SJC Cache-Control: max-age=0, no-cache, no-store, must-revalidate

Content-Language: en

Expires: Wed, 21 Oct 2015 01:00:00 GMT

Link: </pmbd/images/Quantum_PMBD_Logo.png?b9f7d>;rel=preload;as=image

Vary: Accept-Encoding,Cookie

CF-Cache-Status: DYNAMIC

cf-apo-via: origin,host

pragma: no-cache

x-content-type-options: nosniff

x-frame-options: SAMEORIGIN

x-ua-compatible: IE=Edge

Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=K%2BTjI7CiI%2F4k8yZLEdwvoOhvbz0cpig15EZlxH4twqGljNgAyaJcQMZISv7eE6jpH%2FYdU4PiosxUWAnJpSqoGfl% 2Ffw7xxf5HtQYIgxj05VJRbxOfd6X1aw3234VQmZrJzvNp5RM7U6CIFyr1TAMZqtLL5ZUvRA3D%3D"}],"group":"cf-el","max_age":604800}

NEL: {"success_fraction":0,"report_to":"cf- nel","max_age":604800}

Server: cloudflare

The Interpretation was the following:

General

The Pragma header is deprecated. This header field is no longer recommended for use, because of interoperability problems and/or lack of use. See the deprecation notice for more information.

This response explicitly sets a rendering mode for Internet Explorer. This header field is no longer recommended for use, because of interoperability problems and/or lack of use. See the deprecation notice for more information.

Security

This response instructs browsers not to 'sniff' its media type. This header field is no longer recommended for use, because of interoperability problems and/or lack of use. See the deprecation notice for more information.

This response prevents some browsers from rendering it within a frame on another site. This header field is no longer recommended for use, because of interoperability problems and/or lack of use. See the deprecation notice for more information.

Content Negotiation(Content Negotiation response )

The response content is different when content negotiation happens. This header field is no longer recommended for use, because of interoperability problems and/or lack of use. See the deprecation notice for more information.

Content negotiation for gzip compression is supported, saving 59%. This header field is no longer recommended for use, because of interoperability problems and/or lack of use. See the deprecation notice for more information.

Caching

Pragma: no-cache is a request directive, not a response directive. This header field is no longer recommended for use, because of interoperability problems and/or lack of use. See the deprecation notice for more information.

This response can't be stored by a cache. The Cache-Control: no-store directive indicates that this response can't be stored by a cache.

If appending a query string to the file doesn't display the new version of the file, this means the upload didn't succeed, or some permission problem prevented the file from being updated on the destination folder, although MediaWiki would have aborted the upload in that case. Check the filesystem and see if the file was actually replaced by the new version.

Also, you may have inadvertently uploaded the same old version.

Thank you very much for the help. I double checked, I uploaded the new version and it is definitely the right version of the file in the file system, also when I download the file it is always the right version.

I have a new suspicion. The issue only appears when using Microsoft Edge and only with the built in preview from Edge. I also noticed that the URL when previewing the file is not in fact my wiki URL, but starts with https://view.officeapps.live.com/op/view .

Could it be that the browser uses a depreciated version of the file when previewing it?

I don't know what's that preview from Edge, but indeed looks like the issue. It seems to be proxying the opening of that file to an external service (from MS office) that doesn't update its cache

I am seeing a similar problem to AID-PMBD, where Edge seems to cache an old version of an uploaded file regardless of what I do in Apache. I added some "Header set Cache-Control "max-age=60, must-revalidate" to the .htaccess file of the images directory for the file types in question which Firefox seems to obey, but in Edge once I download a file from MW, all subsequent downloads of that same file will match the first downloaded version (regardless of if the file is replaced with a new version in Mediawiki) unless I go to Settings -> Privacy.......->Clear Browsing Data Now and clear the "Cached Images and Files".

Oddly enough, despite this file seemingly existing somewhere, looking at the cache storage under the Dev Tools in Edge does not show anything. I'm sure that's just me doing something wrong, but thought I'd throw it out there.

This issue presents itself with both the "Open" and "Save" download options that Edge gives, no Office Preview stuff involved at all.