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
       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

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

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

Reply via email to