https://bugzilla.wikimedia.org/show_bug.cgi?id=62356
Bug ID: 62356
Summary: SquidPurgeClient.php provides no hooks for extensions
to purge individual files from non-Squid, non-Varnish
content delivery networks
Product: MediaWiki
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: General/Unknown
Assignee: [email protected]
Reporter: [email protected]
Web browser: ---
Mobile Platform: ---
SquidPurgeClient.php seems hard-coded so content delivery network (CDN) nodes
are presumed to be Squid, compatible with HTTP PURGE sent from a trusted IP
address.
This works if the cache acts like a Squid (Varnish is configurable to do this)
but is problematic when dealing with commercial content delivery networks.
Services like CloudFlare (or Amazon AWS) expect the origin server to invoke
their specific proprietary API to signal that a page or file has been
superseded with updated content.
HTTP PURGE likely doesn't even reach them as the long list of IPv4 / IPv6
ranges is normally handled with [[mw:extension:TrustedXFF]] or a proprietary
module (like mod_cloudflare for Apache). Even if it were possible to list the
entire CDN in $wgSquidServers, those servers would ignore a Squid-style PURGE
message.
The end result is that plenty of outdated content is served as the CDN has no
way to know a new version exists until the original version expires from cache.
There needs to be a way to replace the stock SquidPurgeClient with an extension
which provides a function to purge CDN files, but I see no hooks in the code to
allow this. There are [[mw:Manual:CloudFlare#HTTP_purge]] extensions for
WordPress, Drupal and the like but nothing for MediaWiki as the hook to add
such an extension does not exist.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
