Possible hardware issues on the avisynth.nl server

[LigH]

Whoever may be responsible for operating the server http://avisynth.nl - please note that I got the following HTTP error message once while requesting a page:

507 Insufficient Storage

The method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request. There is insufficient free space left in your storage allocation.

Maybe a temporary file directory should be flushed?

[aarv]

Since around October, I've been unable to access avisynth.nl, whether using mobile data or my home Wi-Fi. However, browsing works normally when connecting via VPN to other countries.

MeGUI update server also have same issue, as both sites use the same server (hosting10.whitelabelsolutions.nl).

[LigH]

It is only available via HTTP, not HTTPS. Maybe you are using a web browser which tries to enforce secure connections.

[aarv]

I know, but that's not relevant my issue. I can't even "ping" his server without VPN, It looks like their server have blocked connections from Hong Kong.

[Wilbert]

Thanks for reporting this issue. I will take a look on sunday.

[patul]

+1. I've been in similar situations for about a month, I thought my country (Indonesia) was blocked by the server or any other network infra. As aarv mentioned, VPN solved the issue.

[DTL]

Yes - in the mid-202x 'internet' networks connectivity become worse and worse. Only VPN to some Europe countries helps to reach that server.

[tormento]

Yes - in the mid-202x 'internet' networks connectivity become worse and worse.
In Italy we are lucky enough to have relatively small ISPs that care more about service than money.

You can have nice peering, public IPv4 address, fixed /64 IPv6 in dual stack and a whole lot of fiber bandwidth (usually 2.5/1) for about 29€/month ;)

[Klaus1189]

2.5/1 Gigabits per second for 29€/month?

[tormento]

2.5/1 Gigabits per second for 29€/month?
Even less (~24€) if you have a mobile connection with the same provider. :p

[LigH]

:eek: sobs in German :(

[Klaus1189]

What prodvider can deliver 2.5 Gbit per seconds in download and 1 Gbit per second in upload? That is insane. Sorry for off topic, but I am amazed :)

[microchip8]

What prodvider can deliver 2.5 Gbit per seconds in download and 1 Gbit per second in upload? That is insane. Sorry for off topic, but I am amazed :)

In Belgium, with one of the smaller ISPs, you can get symmetric 2.5/2.5 Gbps down/up. Fastfiber even has a plan that delivers 8.5 Gbps down and 5 Gbps up but it costs nearly 100 euro's

I pay 55 euro's for 1 Gbps down and 500 Mbps up (fiber connection)

[tormento]

What prodvider can deliver 2.5 Gbit per seconds in download and 1 Gbit per second in upload? That is insane. Sorry for off topic, but I am amazed :)
To add insult to injury ;)

https://www.speedtest.net/result/c/d8a9c79e-72ad-4e1b-9a3c-bb98765a0a07.png (https://www.speedtest.net/result/c/d8a9c79e-72ad-4e1b-9a3c-bb98765a0a07)

As a curiosity, what speeds do you reach in your country and for how much?

[Selur]

:eek:
I usually get
https://i.ibb.co/mr4Zz5YW/Bildschirmfoto-2025-11-16-um-15-06-06.png (https://ibb.co/zWZ9fVLv)
I could get a faster download, but that's the max I can get for upload.
¯\_(ツ)_/¯

[LigH]

Deutsche Telekom is allowed to be a quasi-monopolist, no other ISPs really care about digging in the dirt to put cables into (and when they do, the "pink elephant" is bold enough to lay their cables into the groves other companies dug out)... and of course, cities go first, and rural areas "don't need 5G at every milk can".

The era around Helmut Kohl insisted in copper instead of fast fibre. Germany loves being "conservative" and then complains that the world overtakes on the fast lane.

[Swede]

This is my private line which the forum is hosted on (It's a 500/500 at ~€15 a month):

https://forum.doom9.org/bw.png

I've been getting a *lot* of hits the last six months or so, mainly I guess due to all the AI-robots crawling the entire net:

https://forum.doom9.org/hits.png

[Emulgator]

Sorry, could not resist.
Being youngster at the Leipzig Fair 1976-1980, seeing optical cables emerging, ongoing research in East and West Germany.
Availability of fast infrared LEDs in the Mbit/s range even for amateurs, although at a premium (was it 85.-M or so?

1978 verband die Deutsche Bundespost die Vermittlungsstellen in der Aßmannshauser Straße und in der Uhlandstraße in Berlin-Wilmersdorf über eine etwa 4 km lange Verbindungsstrecke aus mehreren Glasfasern. In den folgenden Jahren wurden die Lichtwellenleiter immer weiter verbessert, über immer längere Strecken konnten immer höhere Datenmengen mit immer höheren Datenraten übertragen werden. 1985 zum Beispiel übertrug die British Telecom erstmals Signale ohne Zwischenverstärkung über eine Strecke von 250 km.[2]

1987 entwickelte Heraeus ein Verfahren zur Herstellung von hochreinem, synthetischem Quarzglas aus der Gasphase. Durch synthetisches Quarzglas konnten metallische Verunreinigungen und Feuchtigkeitsspuren des natürlichen Quarzglases um mehrere Größenordnungen reduziert werden. Die von Heraeus produzierten Quarzglas-Vorformen machen rund 95 Prozent der Glasfasern für die optische Nachrichtenübertragung aus.[3]
-----------------------------------
In 1978, the German Federal Post Office (Deutsche Bundespost) connected the telephone exchanges on Aßmannshauser Straße and Uhlandstraße in Berlin-Wilmersdorf via an approximately 4 km long link consisting of several optical fibers. In the following years, optical fibers were continuously improved, enabling the transmission of ever-increasing amounts of data at ever-higher data rates over increasingly longer distances. In 1985, for example, British Telecom transmitted signals without intermediate amplification for the first time over a distance of 250 km.[2]

In 1987, Heraeus developed a process for producing high-purity, synthetic quartz glass from the gas phase. Synthetic quartz glass reduced metallic impurities and traces of moisture found in natural quartz glass by several orders of magnitude. The quartz glass preforms produced by Heraeus account for approximately 95 percent of the optical fibers used for optical communication.[3]

Then the big stall. Each and every US data transmission protocol which had to be adhered to here seemed to insist on copper wire, twisted pairs, or new old coax,
from the 56k modem through any DSL, ADSL, VDSL hitting their old copper wires as hard as they could, wasting kilowatts in driving the next quarter mile's cable capacitance/inductance/resistance at MHz. Light does not have that kind of losses, just attenuation, and no ground loops. Ground loops... Don't get me started..
Who were those copper barons ? Light cable was there, invented, but it could not be laid out.
For decades only as barebones, then slowly to the curb, later into large premise's distribution, but never to the desk.

Now, in 2025 after all copper had been sunk, Deutsche Glasfaser (est.2011) is allowed on the last mile market, and maybe to the desk, IF...
They are mandated to obtain 30% coverage at once to get approval.
How to obtain 30% from a cake which had been sliced and eaten in the last 4 decades ?

What a skewed table is this:
From 1985 on those monopolists had enough time, 40 years after all, to sink their copper cables into german soil,
and to tie ALL AND EVERY end users under their contracts.
I was paying copper, 420.-€ a year, for a measly medium DSL line with landline, 50M down and 2M up.
Older people who are used to having a landline and can not live without pay THE SAME, my father at age 91 paid THE VERY SAME copper bill until his last breath.

Now for me just a mobile hotspot does it, 50M/10M, 8.-€ per month, 96.-€ a year
---
Intel introduced Light Peak at the 2009 Intel Developer Forum (IDF),
using a prototype Mac Pro logic board to run two 1080p video streams plus LAN and storage devices over a single 30-meter optical cable with modified USB ends.[19]
The system was driven by a prototype PCI Express card, with two optical buses powering four ports.[20]
Jason Ziller, head of Intel's Optical I/O Program Office, presented the internal components of the technology under a microscope and the delivery of data through an oscilloscope.[21]
The technology was described as having an initial speed of 10 Gbit/s over plastic optical cables, alongside promising a final speed of 100 Gbit/s.[22]

And then:
In January 2011, Intel's David Perlmutter told Computerworld that initial Thunderbolt implementations would be based on copper wires.[127]
"The copper came out very good, surprisingly better than what we thought," he said.[129]
A major advantage of copper is its ability to carry power. The final Thunderbolt standard specifies 10 W DC on every port....

Muuhahahaaa.

[LigH]

Well, most of the low quality glass fibre cables used for landline phone connections in Germany in the 1980-90's were only capable of carrying 64 kbps per ISDN B-channel (128 kbps in case of dual channel use).

[Wilbert]

Sorry for the late response.
Whoever may be responsible for operating the server http://avisynth.nl - please note that I got the following HTTP error message once while requesting a page:

Maybe a temporary file directory should be flushed?

My provider increased some php limits. I hope that solves this problem, but let me know when this issue comes back.

@All. Some countries where abuse IP's often come from are blocked by my provider. Sorry about this, but there is nothing i can do about that.

[real.finder]

@Wilbert

is the spam answer not working? I cant add https://forum.doom9.org/showpost.php?p=1951405&postcount=67 to http://avisynth.nl/index.php/Crt_display

[Wilbert]

When i tried to upload the script i got an error message. Something like 'File extension does not match MIME type text/plain'. I don't understand why it didn't work anymore. I added avsi and avs to mime.types and was able to upload the file for you (http://avisynth.nl/index.php/File:Crt_display.avsi).

[real.finder]

I added avsi and avs to mime.types and was able to upload the file for you (http://avisynth.nl/index.php/File:Crt_display.avsi).

thanks! I did add it to the wiki

[magnetite]

I went to go get the latest MTModes.avsi from this site, and it came up with an warning from my antivirus.


Suspicious page blocked for your protection
https://avisynth.nl/

Your connection to this web page is not safe due to an unmatching security certificate.
This means that the certificate was issued for a different web address than the one it is being used for, and you run the risk of exposing your data by accessing this page.

[LigH]

You may have to add an exception to your security suite or use the protocol http: - not https: ... unless Wilbert is able to get a matching certificate for possibly several domains per same server.

[hello_hello]

I think this is the latest version that'll definitely work. It's the one I'm using. Newer versions seem to have been unnecessarily edited and/or contain non-English characters.
https://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/rev.1011
You can download a newer version from that link if you like though.

[VoodooFX]

It's down for some time with "Resource Limit Is Reached" or "Insufficient Storage" error.

[ChaosKing]

just refresh it a couple times then it loads.

[Wilbert]

So i mailed my hosting company this week. They showed me a part of the log of some particular day (as example), and explained why much resources are being used. For example because spam links (they still exist, see below ) are being indexed and bots are doing searches on those links.

The dead end pages looked a good candidate to me for finding out which spam links are still there (i'm not sure if it is complete): http://www.avisynth.nl/index.php?title=Special:DeadendPages&limit=500&offset=0. I will remove all of them when i have some time. They also advised to remove some bad search engines from the .htaccess file. So my .htaccess file (in /domains/avisynth.nl/public_html/) looks like this:

php_value register_globals 0

RewriteEngine On

RewriteCond %{HTTP_USER_AGENT} ^(.*)msnbot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)MJ12bot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)SolomonoBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)Yandex [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)Baiduspider [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)Yeti [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)Mail.Ru [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)exabot [NC]
RewriteRule .* - [F]


If you have some other ideas or suggestions let me know.

[ChaosKing]

To reduce the load you could cache whole pages for guests https://www.mediawiki.org/wiki/Manual:File_cache

Scroll to "Serving cached pages directly"

[Adub]

The wiki has become pretty much unusable for me, at least in the States, not sure how accessible it is in the rest of the world.

Reading this forum thread, it sounds like you're using some kind of wiki hoster, and not a dedicated VPS.

While the rewrite conditions may help a little bit, a lot of new AI scrapers change their User Agent to look like a normal browser, so you're not making much of an impact.

You'll likely see the biggest change by 1) deleting the spam links you talk about, and 2) serving cached pages.

I don't know what your specific hosting setup, but there's a lot of different caching technologies available today. Vinyl Cache (https://vinyl-cache.org/) (previously Varnish Cache) is purpose built for this kind of job, but there are other options like the cache handler plugin for the Caddy webserver (https://github.com/caddyserver/cache-handler).

Speaking of Caddy, it supports PHP via FrankenPHP (https://frankenphp.dev/), which is a very fast PHP implementation in Go. Switching to that alone may see a marked impact on your hosting performance.

Then of course there's changing servers, but I imagine you're trying to stick with what you have.

I can give more advice, but it would depend on your specific hosting details and what changes you're willing to make/not make.

Credentials: I was a Senior SDE in Big Tech for ~14 years, specializing in backend, distributed systems, and ~5 years of frontend development.

[Wilbert]

Thanks both of your for offering your help.
1. I removed the rest of the spam links this afternoon (i hope it did it correctly).
2. I uploaded some stats and logs of avisynth.nl (of july). I hope it's of some help to you ;)
* stats (http://wilbertdijkhof.nl/Usage%20Statistics%20for%20avisynth.nl_202607.png)
* stats-2 (http://wilbertdijkhof.nl/Usage%20Statistics%20for%20avisynth.nl_202607-2.png)
* WebUsageLog_last100lines (http://wilbertdijkhof.nl/WebUsageLog_last100lines.png)

As you can see since May the increase in the number of hits is just crazy.

@ChaosKing, I wanted to try your suggestion (cache whole pages for guests in .htaccess). But i'm stuck.

I was reading your link https://www.mediawiki.org/wiki/Manual:File_cache#Serving_cached_pages_directly. They give an example (ok they say it doesn't work for punctuation or non-ASCII characters):

RewriteBase /
# If a cached page exists under /w/html_cache, do an internal redirect to it:
RewriteCond %{HTTP_COOKIE} !UserID=
RewriteCond %{QUERY_STRING} !.
RewriteCond %{DOCUMENT_ROOT}/w/html_cache/$1.html -s
RewriteRule ^wiki/(.+)$ /w/html_cache/$1.html [B,L,NS]

What should happen if i apply it to http://avisynth.nl/index.php/Main_Page? Or should i change it? I have to admit i don't know what it does and what the result should be. I guess the values of the variables are explained here (https://httpd.apache.org/docs/2.4/expr.html), but i didn't check yet?

I found a website (https://htaccess.madewithlove.com/) to test the example above. It says
* conditions 1-3 are met.
* condition 4: Unsupported TestString: %{DOCUMENT_ROOT}/w/html_cache/$1.html
* condition 5: This rule was not met.

I hope you can clarify some things and we can get it working.

@Adub, Yes the wiki is unusable here (Europe) too. My hosting company hosts the wiki (and i'm not sure a VPS server).

[ChaosKing]

Some line by line explanations:
Line-by-line:

RewriteBase /
Base path for relative rewrites = site root. All following rules resolve against /.

RewriteCond %{HTTP_COOKIE} !UserID=
Match only if NO UserID= cookie. Means: anonymous visitor. Logged-in users skip cache, get dynamic page.

RewriteCond %{QUERY_STRING} !.
Query string must be empty (. = any char, ! negates). URL like /wiki/Page?action=edit bypasses cache.

ReWriteCond %{THE_REQUEST} ^GET\x20/wiki/([^\x20/]+)\x20HTTP
Match raw HTTP request line: GET /wiki/PageName HTTP/1.1. \x20 = space. Captures page name (no space, no slash) into %1. Only GET; POST etc. bypass. THE_REQUEST is the original, non-URL-decoded request — so %1 keeps percent-encoding exactly
as browser sent it.

RewriteCond %{DOCUMENT_ROOT}/w/html_cache/%1.html -s
Check file <docroot>/w/html_cache/PageName.html exists AND size > 0 (-s). %1 = capture from previous cond. Empty/missing cache file falls through to PHP.

RewriteRule ^wiki/(.+)$ /w/html_cache/%1.html [B,L,NS]
All 4 conds true: internally rewrite /wiki/Page to /w/html_cache/Page.html. Internal = browser URL unchanged, Apache serves static file, PHP never runs. Flags:
- B — re-escape backreference (special chars in page name stay safely encoded in filesystem path)
- L — last rule, stop rewrite processing
- NS — skip for internal subrequests, only apply to real client requests

Net effect for avisynth.nl: anonymous GET of /wiki/X with no query string, cache file present — Apache serves static HTML directly. Fast, zero PHP/DB load. Everyone else hits MediaWiki normally.


I think this should work for avisynth.nl RewriteCond %{THE_REQUEST} ^GET\x20/index\.php/([^\x20/]+)\x20HTTP

complete code
RewriteCond %{HTTP_COOKIE} !UserID=
RewriteCond %{QUERY_STRING} !.
RewriteCond %{THE_REQUEST} ^GET\x20/index\.php/([^\x20/]+)\x20HTTP
RewriteCond %{DOCUMENT_ROOT}/html_cache/%1.html -s
RewriteRule ^index\.php/(.+)$ /html_cache/%1.html [B,L,NS]



btw the site reports now: Insufficient Storage aka no free space left.

You don't get frankenphp on simple webhosting (nginx if you're lucky). And it's not really faster. Main reason is the much easier setup + worker mode.

[Wilbert]

Thanks. Some follow up questions:

1. The 'Serving cached pages directly' sections says also to set: $wgFileCacheDepth = 0; // get's intermediate directories entirely

Is this necessary? I guess it needs to be added in LocalSettings.php.

2. So when all four conditions are true, for example,
http://avisynth.nl/index.php/Main_Page is rewritten as <DOCUMENT_ROOT>/html_cache/Main_Page.html right?

I assume i should have cached pages like this on my laptop? How do i know what the location is of <DOCUMENT_ROOT>? Or are these cached files on my wiki server?

You don't get frankenphp on simple webhosting (nginx if you're lucky).
I see I can install CakePHP on the server. Is that something similar?

[ChaosKing]

Thanks. Some follow up questions:

1. The 'Serving cached pages directly' sections says also to set: $wgFileCacheDepth = 0; // get's intermediate directories entirely

Is this necessary? I guess it needs to be added in LocalSettings.php.

2. So when all four conditions are true, for example,
http://avisynth.nl/index.php/Main_Page is rewritten as <DOCUMENT_ROOT>/html_cache/Main_Page.html right?

I assume i should have cached pages like this on my laptop? How do i know what the location is of <DOCUMENT_ROOT>? Or are these cached files on my wiki server?


I see I can install CakePHP on the server. Is that something similar?


CakePHP is a php framework like Symfony or Laravel. Has nothing to do with mediawiki.

The basic idea is to cache/save all avs-mediawiki pages as html file. This way php is not called at all and everything is served by the webserver directly. Which should be much faster and uses less resources. Everything is stored on the webserver, no laptop involvement needed.

'DOCUMENT_ROOT'
The document root directory under which the current script is executing, as defined in the server's configuration file.

https://www.php.net/manual/en/reserved.variables.server.php

Site feels fast again, success!?

BTW: If I see this correctly your installed mediawiki version is very old ~10 years, pls update!

[Adub]

Just double checking, $wgUseFileCache has been set to 'true' in LocalSettings.php, correct? I only ask because it wasn't mentioned in your updates.

Also, as ChaosKing mentioned, make sure you're using the latest version of MediaWiki, as there are a multitude of performance improvements that we can engage in the latest version (with the file cache being the main one, but there are others like PHP's Op cache).

Edit:

Also, ChaosKing's "completed code" section is missing a "/w" when referencing the cache path. You can confirm the correct cache path by looking at the corresponding directory on your webserver, but that path has to be correct in order to reference the generated html files properly

[Wilbert]

I didn't make any changes yet ;) I just want to be sure i understand everything before doing something.

Just double checking, $wgUseFileCache has been set to 'true' in LocalSettings.php, correct? I only ask because it wasn't mentioned in your updates.

No not yet, so i should add the following in LocalSettings.php right?

$wgUseFileCache = true; // activate the server-side file cache
$wgFileCacheDepth = 0;

So the html files are cached on the server in this location(?) $wgFileCacheDirectory = "{$wgUploadDirectory}/cache".

Also, as ChaosKing mentioned, make sure you're using the latest version of MediaWiki, as there are a multitude of performance improvements that we can engage in the latest version (with the file cache being the main one, but there are others like PHP's Op cache).

I guess it's better to update MediaWiki first before making the cache changes? I will do this the next weekend.

Edit:

Also, ChaosKing's "completed code" section is missing a "/w" when referencing the cache path. You can confirm the correct cache path by looking at the corresponding directory on your webserver, but that path has to be correct in order to reference the generated html files properly

So it should be the following?

RewriteCond %{HTTP_COOKIE} !UserID=
RewriteCond %{QUERY_STRING} !.
RewriteCond %{THE_REQUEST} ^GET\x20/index\.php/([^\x20/]+)\x20HTTP
RewriteCond %{DOCUMENT_ROOT}/w/html_cache/%1.html -s
RewriteRule ^index\.php/(.+)$ /w/html_cache/%1.html [B,L,NS]

I'm a bit puzzled by this cache folder. This should be the location right?

Setup.php:
if ( $wgFileCacheDirectory === false ) $wgFileCacheDirectory = "{$wgUploadDirectory}/cache";
if ( $wgUploadDirectory === false ) $wgUploadDirectory = "$IP/images";

thus $wgFileCacheDirectory = "{$wgUploadDirectory}/cache" = "$IP/images/cache"

$IP should be the current working directory. Is this /domains/avisynth.nl/public_html?

There is no cache folder in /domains/avisynth.nl/public_html/images. I guess this will be created automatically?

There does exist a folder /domains/avisynth.nl/public_html/cache, but this is empty (except for some .htaccess file with the contents: Deny from all). That seems to be the following variable (from LocalSettings.php):

## Set $wgCacheDirectory to a writable directory on the web server
## to make your wiki go slightly faster. The directory should not
## be publically accessible from the web.
#$wgCacheDirectory = "$IP/cache";

Sorry for all those basic remarks, but it's a long time ago i looked at this stuff.

[Adub]

Honestly, good idea not to make any changes.

I think focusing on the MediaWiki upgrade first is a good idea. That will ensure any configuration changes we make are based on current documentation.

Note that you’ll likely have database changes involved in your change. That’s standard, but important to call out.

Start with making a full backup of the sites files and database, as upgrades can go sideways and a backup will be critical for recovery.

Im going to look into spinning up a local MediaWiki instance for my own testing. That will ensure I have a solid source of truth for any possible configuration ideas we have.

[Adub]

No not yet, so i should add the following in LocalSettings.php right?

$wgUseFileCache = true; // activate the server-side file cache
$wgFileCacheDepth = 0;



Yes, this looks correct to me, based on the documentation for the latest MediaWiki version.

The $wgCacheDirectory variable appears to be for something else entirely. (https://www.mediawiki.org/wiki/Manual:$wgCacheDirectory)



RewriteCond %{HTTP_COOKIE} !UserID=
RewriteCond %{QUERY_STRING} !.
RewriteCond %{THE_REQUEST} ^GET\x20/index\.php/([^\x20/]+)\x20HTTP
RewriteCond %{DOCUMENT_ROOT}/w/html_cache/%1.html -s
RewriteRule ^index\.php/(.+)$ /w/html_cache/%1.html [B,L,NS]


In theory this is correct based on the wiki documentation, but the real path will depend on what $wgFileCacheDirectory is actually set to. The nice thing is we can make these changes one at a time.

First, (after updating MediaWiki), enable $wgUseFileCache, then check your server to find the specific directory (should be whatever $wgFileCacheDirectory is set to). Then once you confirm the correct location, we can update the Apache rules accordingly.

[WalkyrieVanguard]

Anyone have any idea when the site will be back or EXACTLY what is going on? Has the owner considered transferring ownership?

[StainlessS]

Avisynth.nl is up for me now at time of this post.

[Wilbert]

Last couple of day it was working, until yesterday. Yesterday i was making offline backups and updating the wiki. Perhaps that's why it is not accessible again.

My progress. The wiki is updated to version 1.29.2. Before updating to the latest version, i need to update the PHP version first because recent MediaWiki versions require this. I think i can do this myself, but the website needs to be accessible first.

I'm a bit worried about the update process though. When updating the first time the size of the backup was reduced from 2959 MB to 166 MB. So you would think that something is missing, but i don't understand what. When the website is accessible again i will do some checking first: backups_online (http://wilbertdijkhof.nl/backups_online.jpg)

[ChaosKing]

I'm a bit worried about the update process though. When updating the first time the size of the backup was reduced from 2959 MB to 166 MB. So you would think that something is missing, but i don't understand what. When the website is accessible again i will do some checking first: backups_online (http://wilbertdijkhof.nl/backups_online.jpg)

I would extract both backups and compare them. One of my favorite tool for it: https://winmerge.org/

Is it maybe an incremental backup?

[Wilbert]

I did the following updates:
* PHP 8.4
* Mediawiki 1.46.0

I added the following lines in LocalSettings.php in /domains/avisynth.nl/public_html/:

$wgUseFileCache = true;
$wgFileCacheDepth = 0;

In the folder
$wgFileCacheDirectory = "{$wgUploadDirectory}/cache" = "$IP/images/cache"
where
$IP = current working directory = /domains/avisynth.nl/public_html

I see more files than the last time:
http://wilbertdijkhof.nl/wgFileCacheDirectory.jpg

I guess this is indeed the location of $wgFileCacheDirectory.

[Adub]

Awesome, congrats on the successful upgrade! Handling the multiple version jumps was likely a bit arduous, so big kudos.

And okay, that image of the html cache is looking very promising.

Based on that image and this documentation (https://www.mediawiki.org/wiki/Manual:File_cache#Apache), I think you can update the Apache htaccess to something like the following:


RewriteCond %{HTTP_COOKIE} !UserID=
RewriteCond %{QUERY_STRING} !.
RewriteCond %{THE_REQUEST} ^GET\x20/index\.php/([^\x20/]+)\x20HTTP
RewriteCond %{DOCUMENT_ROOT}/images/cache/ns0\%3A%1.html -s
RewriteRule ^index\.php/(.+)$ /images/cache/ns0\%3A%1.html [B,L,NS]


This should cause Apache to start serving the html files directly. You can confirm this is cache file serving is working by looking at the access logs for Apache and MediaWiki/PHP. Once the htaccess updates have been made, you should see the requests in the Apache logs but *not* in the MediaWiki/PHP logs, since they are completely bypassed at that point.

As a bonus once that's working, we could try enabling precompressed GZIP support, which has several benefits including smaller disk usage for the cache and faster response times since there's fewer bytes going over the wire and Apache isn't doing any extra compression.

https://www.mediawiki.org/wiki/Manual:File_cache#Compression

[LigH]

Down again:

508 Resource Limit Is Reached

Also:

507 Insufficient Storage

PS: The plugins archive definitely needs a mirror. For an hour now I'm trying to find plugins in both 32 and 64 bit variants with all dependencies and possible workarounds for those I could not find outside the Wiki ...

[Wilbert]

@Adub, ChaosKing,

I updated .htaccess in /domains/avisynth.nl/public_html/. It contains

php_value register_globals 0

RewriteEngine On

RewriteCond %{HTTP_USER_AGENT} ^(.*)msnbot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)MJ12bot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)SolomonoBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)Yandex [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)Baiduspider [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)Yeti [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)Mail.Ru [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)exabot [NC]
RewriteRule .* - [F]

RewriteCond %{HTTP_COOKIE} !UserID=
RewriteCond %{QUERY_STRING} !.
RewriteCond %{THE_REQUEST} ^GET\x20/index\.php/([^\x20/]+)\x20HTTP
RewriteCond %{DOCUMENT_ROOT}/images/cache/ns0\%3A%1.html -s
RewriteRule ^index\.php/(.+)$ /images/cache/ns0\%3A%1.html [B,L,NS]

Question. I don't need to add a 'RewriteBase /' somewhere?

As far as i know that there are no access logs for MediaWiki/PHP. I can only see the number of hits (see post #32). I have access to the Apache access logs.

@LigH, I know. We were not ready with the changes. I noticed that after the previous changes the site was accessible during the night, but not during the day (wrt greenwich time).

[ChaosKing]

@Adub, ChaosKing,

I updated .htaccess in /domains/avisynth.nl/public_html/. It contains


Question. I don't need to add a 'RewriteBase /' somewhere?

As far as i know that there are no access logs for MediaWiki/PHP. I can only see the number of hits (see post #32). I have access to the Apache access logs.

@LigH, I know. We were not ready with the changes. I noticed that after the previous changes the site was accessible during the night, but not during the day (wrt greenwich time).


Claude check:
no, you don't need RewriteBase / — the .htaccess sits in the document root (default base is already /), and your substitutions either start with / or are -, so RewriteBase wouldn't change anything.

The actual problem is in the cache rewrite rule. I tested against the live server:

- http://avisynth.nl/index.php?title=External_filters → 200, so MediaWiki itself is fine.
- http://avisynth.nl/index.php/External_filters → Apache-level 404 ("Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument"), so the request never reaches MediaWiki — the cache rule fires and
points to a file that isn't found.
- http://avisynth.nl/images/cache/ns0%3AExternal_filters.html → 404
- http://avisynth.nl/images/cache/ns0%253AExternal_filters.html → 200

The cache files on disk are named with a literal percent sign (ns0%3AExternal_filters.html — that's how MediaWiki's file cache writes them). Your rule substitutes /images/cache/ns0%3A...html, and during the internal redirect Apache
URL-decodes the literal %3A back to :, so it looks for ns0:External_filters.html, which doesn't exist — hence the 404.

The flag only protects the backreference %1 (it escapes _ to %5f, which survives the decode). The literal %3A in the substitution gets decoded once, so it needs to be double-encoded:

[B] RewriteRule ^index\.php/(.+)$ /images/cache/ns0\%253A%1.html [B,L,NS]

Only that one line needs to change. The RewriteCond ... -s line is correct as is — that's a filesystem check, nothing gets decoded there, so \%3A is right in that context.

Unrelated: php_value register_globals 0 has been dead since PHP 5.4 — you can drop that line. It's harmless right now (mod_php is running, otherwise the whole site would 500), but it does nothing.

Thanks!

[Adub]

Ah ChaosKing beat me to it - yeah, I missed the \%25 detail, that's on me.

So the proper config should be:


RewriteCond %{HTTP_COOKIE} !UserID=
RewriteCond %{QUERY_STRING} !.
RewriteCond %{THE_REQUEST} ^GET\x20/index\.php/([^\x20/]+)\x20HTTP
RewriteCond %{DOCUMENT_ROOT}/images/cache/ns0\%3A%1.html -s
RewriteRule ^index\.php/(.+)$ /images/cache/ns0\%253A%1.html [B,L,NS]

[LigH]

@Wilbert: OK, patience, and best success to you!

[Reel.Deel]

@Wilbert - is it possible to redirect "https://avisynth.nl/" to the front page? Right now it's just a blank page that says "webserver is functioning normally".

@LigH - I use archive.org in the meantime. Most of the external plugins subpages are archived.

[LigH]

Indeed, should know that ... for now I found everything I needed and got quite nice results trying to restore and upscale a music video.

Someone please hire me.

[Wilbert]

Ok thanks! I corrected the RewriteRule line.

The special pages link http://avisynth.nl/index.php/Special:Preferences gives an internal error (after upgrading Mediawiki). It seems the same problem as here https://issue-tracker.miraheze.org/T11444, but i don't have $wgHiddenPrefs[] set in my LocalSettings.php. I will try to find the problem later. I don't understand how these people make those backtraces?

Note to myself, when looking at the source of this page it suggests to set '$wgShowExceptionDetails = true' to show detailed debugging. Will try that later.

@Reel.Deel,
I don't know. I will check about this.

[Adub]

Okay, things are starting to look better, some pages appear to be served from the file cache.

The home page isn't (which kind of makes sense given the htaccess rules we've created so far, as they only pertain to sub pages), and Category pages (like http://avisynth.nl/index.php/Category:AviSynth_Usage) don't appear to be using the file cache either yet.

I'm curious if things like the Category pages have a different filename structure in the cache, which would warrant a different htaccess rule to serve properly.

I've also noticed some other issues:

1. Pages served from the file cache are sent with a CSP header like the following, which prevents loading the main CSS theme:


Content-Security-Policy: default-src 'none'; style-src 'unsafe-inline' data:; font-src data:; img-src data: 'self'; media-src data: 'self'; sandbox


I'm a bit surprised by these values. Specifically "style-src 'unsafe-inline' data:;" means that requests for CSS files on the same domain are not allowed. An additional value of 'self' is required at the very least. Most sites are fine with just setting something like


Content-Security-Policy: default-src 'self'; sandbox


This might need to be updated if any pages use inline styles or data: encoded values.

2. HTTPS hasn't been enabled properly for the avisynth.nl domain.

Interestingly, the server is sending Upgrade: h2,h2c response headers, which encourages the browser to upgrade to HTTP2, but proper support requires HTTPS enabled.

How about finally enabling HTTPS on avisynth.nl, likely using something like the mod_md Apache module which has ACME support to automatically retrieve and rotate certifcates? https://httpd.apache.org/docs/trunk/mod/mod_md.html

[Wilbert]

I'm curious if things like the Category pages have a different filename structure in the cache, which would warrant a different htaccess rule to serve properly.
I don't see Category pages in the cache folder. Also the files start from ns0 up to ns15 (so not just ns0).

Let's address the first point first.
1. Pages served from the file cache are sent with a CSP header like the following
Sorry, i'm lost. How do you know they are sent with a CSP header like this? How do you know that this prevents loading of the main CSS theme?

https://www.mediawiki.org/wiki/Manual:$wgCSPHeader says (see second part)
As an anti-XSS measure
Warning Warning: As of MediaWiki 1.41 (Gerrit change 945958, git #b28faecb), support for nonces in the Content-Security-Policy header has been removed, and it's required to have unsafe-inline in the script-src directive for JavaScript to work. This practically defeats the purpose of having a Content Security Policy as an anti-XSS measure, as inline JavaScript is one of the most common attack vectors.
But i don't really know what i'm talking about.

Remark. After logging out it was almost impossible to log in, because these links (special pages) were not visible in the cached files (like http://www.avisynth.nl/index.php?title=Special:UserLogin in the upper right corner).

[Adub]

Sorry, i'm lost. How do you know they are sent with a CSP header like this? How do you know that this prevents loading of the main CSS theme?


You can see the header value using the Network Tools built in to your browser. I've attached a screenshot that shows the request for the main page, the blocked CSS call, and the CSP header value as sent by your webserver.

The CSP header is set by either MediaWiki or Apache. The latter has the final say in what the header is as it can override MediaWiki's value.

Since the header is set on files served from the cache, then Apache is what must be setting the header. I'd double check your Apache configuration - not just the htaccess file, but also the main Apache configuration that applies to all sites that are hosted on the server. Some Apache configuration is setting the header value to what I previously posted / what's in the screenshot.

[Wilbert]

There are pages in the cache folder starting from ns0 up to ns15 (so not just ns0). I added rewrite rules for these in the .htaccess file.

As usual there something i don't understand. There are still a lot pages missing in the cache folder, for example http://www.avisynth.nl/index.php/Convert. I noticed this page (and many more) are here in a subfolder called history: /domains/avisynth.nl/public_html/images/cache/history/ ImageSource for example in both in the cache folder and the history subfolder. Why is this and what should i do with this?

edit. it's explained here: https://www.mediawiki.org/wiki/Manual:RebuildFileCache.php. I just the history of a page which is also cached.

@Adub,
Thanks for attachment. I understand that part now.


// old: Content-Security-Policy: default-src 'none'; style-src 'unsafe-inline' data:; font-src data:; img-src data: 'self'; media-src data: 'self'; sandbox
Content-Security-Policy: default-src 'self'; sandbox


This might need to be updated if any pages use inline styles or data: encoded values.
1. What do you mean by the encoded values?

2. So i guess we need to find out with this CSP stuff is set? For example /etc/httpd/conf/httpd.conf and update it. I don't have access to the Apache configuration myself (afaik), so i guess i should ask my hosting company to make those changes right? At least i don't see it in the DirectAdmin panel.

Some documentation about CSP for myself:
* https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
* https://www.dchost.com/blog/en/http-security-headers-guide-how-to-correctly-set-hsts-csp-x-frame-options-and-referrer-policy/#CSP_Content-Security-Policy

[Adub]

There are still a lot pages missing in the cache folder

It's unlikely that they are missing - just that they haven't been accessed yet. The cache is populated based on page access - meaning that files will be missing from the cache up until someone accesses a page for the first time. For you Convert example - it's being served from cache now (which you can tell because of the aforementioned CSP header blocking CSS on that page now).

What do you mean by the encoded values?

All CSP header values can be referenced at https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP

In this case, by specifying default-src 'self', we're saying that by default, any resource (JS, CSS, images, etc) served by *this* domain (self) are considered safe and can be loaded. This is a pretty safe default, as it basically says to trust only this domain, but all resources from it. The CSP configuration can be extended on a case by case basis to allow loading resources (like images or javascript) from other sites.

Since the wiki seems to use javascript <script> elements in a few places, you'll also need the script-src 'self' 'unsafe-inline'; value to ensure those scripts are executed properly. More details: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/script-src#unsafe_inline_script

Note that you can update this header value in your htaccess file. If you aren't able to control the default value for some reason, then you can try something like the following in your htaccess file:


Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline';"


You'll likely want to add this entry into your configuration for serving files from the cache.

[Wilbert]

I just update the .htaccess file to:
Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline';"

RewriteEngine On

RewriteCond %{HTTP_USER_AGENT} ^(.*)msnbot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)MJ12bot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)SolomonoBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)Yandex [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)Baiduspider [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)Yeti [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)Mail.Ru [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)exabot [NC]
RewriteRule .* - [F]

RewriteCond %{HTTP_COOKIE} !UserID=
RewriteCond %{QUERY_STRING} !.
RewriteCond %{THE_REQUEST} ^GET\x20/index\.php/([^\x20/]+)\x20HTTP
RewriteCond %{DOCUMENT_ROOT}/images/cache/ns0\%3A%1.html -s
RewriteRule ^index\.php/(.+)$ /images/cache/ns0\%253A%1.html [B,L,NS]

RewriteCond %{HTTP_COOKIE} !UserID=
RewriteCond %{QUERY_STRING} !.
RewriteCond %{THE_REQUEST} ^GET\x20/index\.php/([^\x20/]+)\x20HTTP
RewriteCond %{DOCUMENT_ROOT}/images/cache/ns1\%3A%1.html -s
RewriteRule ^index\.php/(.+)$ /images/cache/ns1\%253A%1.html [B,L,NS]

(...) same for ns2 upto ns15

If it doesn't work i will ask the hosting company to update the apache configuration.

It's unlikely that they are missing - just that they haven't been accessed yet. The cache is populated based on page access - meaning that files will be missing from the cache up until someone accesses a page for the first time. For you Convert example - it's being served from cache now (which you can tell because of the aforementioned CSP header blocking CSS on that page now).
Ok i see. I see you can run the maintenance script rebuildFileCache.php to build the cache file for all content pages at once. I will check later how to do this (i don't have time for this the coming weeks). Hopefully we will see some big improvements then. At this moment it's loading without problems (being logged in), but yesterday afternoon i got those 'not accessible' warnings again. I guess in that case you need to log off to browse the website (but then you can't update anything when being offline).

[Adub]

The header isn't taking effect - you can confirm this for yourself by loading http://www.avisynth.nl/index.php/Convert. CSS doesn't load (thus the visual differences), but you can see the exact (failing) requests using the Network tab in your browser's dev tools.

As for why it's not working - I'm not sure. I don't have insights into your exact hosting setup, so it's difficult to for me to say exactly why.

Your hosting provider should be able to tell you for sure though.

[Wilbert]

When inspecting it (or any other page), it now says:

Content-Security-Policy
default-src 'self'; script-src 'self' 'unsafe-inline';
Content-Type
text/html; charset=UTF-8
Date
Sun, 16 Aug 2026 20:16:34 GMT

So this is as we wanted right? I removed ns0%3AConvert.html from the cache folder and accessed this page again when being logged in (so it was cached again). But the cached page (dated today) still looks bad. Are you sure the proposed CSP line is correct?

[Adub]

I suggest looking at the headers for http://www.avisynth.nl/index.php/Convert again.

I'm seeing:


Content-Security-Policy: default-src 'none'; style-src 'unsafe-inline' data:; font-src data:; img-src data: 'self'; media-src data: 'self'; sandbox


Which explains why the page "still looks bad".

The main page http://avisynth.nl/ appears to have the header set correctly.

So cached pages are not yet being served with the new CSP values.

[ChaosKing]

I noticed that too. Easiest fix is to clear the cached version I guess.

[Wilbert]

Yes my bad. The cached pages are not being served with the new CSP values:
Example: http://www.avisynth.nl/index.php/Convert
logged on: Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline';
logged off: Content-Security-Policy: default-src 'none'; style-src 'unsafe-inline' data:; font-src data:; img-src data: 'self'; media-src data: 'self'; sandbox

@ChaosKing,
I removed the cached page above (Convert) and after visiting it was added again. But it is still has the wrong CSP values.

I will ask my hosting company, but that has to wait a coupled of weeks. I don't have time for this now.

[ChaosKing]

Is there a .htaccess in your cache folder, if not create one and add
<IfModule mod_headers.c>
Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline';"
</IfModule>


And see if your hoster offers free SSL like LetsEncrypt so we all can enjoy https :-)

[wonkey_monkey]

And see if your hoster offers free SSL like LetsEncrypt so we all can enjoy https :-)

Any hoster that doesn't, in 2026, is a bad sign in my book. A host I was with offered it, though it had to be manually renewed when it expired. Not a big deal. Then they got bought out, and took away free SSL. Email auto-config stopped working, then email had many outages and it took two weeks for them to even acknowledge a problem. The last straw was a malicious script appearing in my files that they didn't care to investigate.