Ga naar inhoud

De CDN leegmaken vanuit je site

Met de knop Cache legen op de CDN-pagina van een site maak je de hele CDN-cache met de hand leeg (zie CDN en Shield). Wil je dat automatisch laten gebeuren — aan het eind van een deployscript, of na een grote import van content — dan kun je de purge vanuit de site zelf aanvragen, met één HTTP-verzoek en zonder API-sleutel.

Voordat je begint

  • Een site waarvan de CDN actief is.
  • Een shell op de site: een SSH-verbinding of Cloud Shell (zie Toegang tot je bestanden), of code die in de site zelf draait.

Wat je site al heeft

Elke site krijgt twee omgevingsvariabelen die het verzoek autoriseren. Je hoeft zelf geen inloggegevens aan te maken of te kopiëren.

Variabele Wat erin staat
METADATA_SERVICE Het adres van de metadataservice van het platform, http://metadata.internal:8500.
METADATA_AUTH Een token dat je site identificeert. Het platform bepaalt alleen aan de hand van dit token welke site wordt leeggemaakt.

Beide zijn ingesteld in een SSH- of Cloud Shell-sessie, dus de voorbeelden hieronder werken daar zoals ze er staan. PHP-code die in de site draait, zoals een plug-in, kan ze uitlezen met getenv().

Cronjobs krijgen deze variabelen niet

Een job in het crontab-bestand van de site draait met een vrijwel lege omgeving, dus $METADATA_SERVICE en $METADATA_AUTH zijn daar leeg en het verzoek mislukt.

De hele site leegmaken

curl -sS -X POST "$METADATA_SERVICE/v1/actions" \
  -H "Authorization: Bearer $METADATA_AUTH" \
  -H "Content-Type: application/json" \
  -d '{"action_type":"cdn_purge","params":{"mode":"all"}}'

Specifieke paden leegmaken

Stuur "mode": "paths" mee met een lijst van maximaal 100 paden:

curl -sS -X POST "$METADATA_SERVICE/v1/actions" \
  -H "Authorization: Bearer $METADATA_AUTH" \
  -H "Content-Type: application/json" \
  -d '{
    "action_type": "cdn_purge",
    "params": {
      "mode": "paths",
      "paths": ["/blog/hello-world", "/wp-content/uploads/*", "/shop/"]
    }
  }'

Elk pad wordt achter de CDN-hostnaam van de site geplakt:

  • Een pad dat eindigt op / of een * bevat, maakt alles daaronder leeg — in het voorbeeld heel /wp-content/uploads/ en heel /shop/.
  • Elk ander pad maakt precies die ene URL leeg.
  • Ontbreekt de / aan het begin, dan wordt die voor je toegevoegd.

Soms wordt in plaats daarvan de hele site leeggemaakt

Staat Aanvraag-hostnaam aan onder Vary Cache op de CDN-pagina van de site, of heeft de site geen CDN-hostnaam, dan maakt een verzoek met paden de hele cache leeg.

Wat je terugkrijgt

Een geslaagd verzoek geeft 202 Accepted terug:

{"id":"3f0c9a1e-5b7d-4c2a-9e61-0d8f2b4a7c13","status":"pending"}
Status Betekenis
202 Het verzoek is vastgelegd. Het platform pakt het op.
400 De body is geen geldige JSON, action_type ontbreekt of is langer dan 128 tekens, of params is groter dan 64 KB.
401 De Authorization-header ontbreekt, of het token wordt niet herkend.
429 Te veel verzoeken. Elke site kan er 20 kort achter elkaar sturen, daarna 2 per seconde.

Fouten komen terug als {"error": "…"}.

Een 202 is geen bevestiging

202 betekent alleen dat het verzoek is vastgelegd. De purge zelf draait iets later, en je site krijgt niets terug over of die is uitgevoerd. De waarden van mode en paths worden bij het versturen ook niet gecontroleerd — een ongeldige mode, een lege paths-lijst of meer dan 100 paden wordt later weggegooid zonder dat er een fout bij je terechtkomt. Een site zonder actieve CDN wordt eveneens stilzwijgend overgeslagen.

Controleren of de purge is uitgevoerd

Een purge die doorgaat, verschijnt op de pagina Activiteit van de site als CDN-cache legen, met Systeem in de kolom Uitgevoerd door. De status laat zien of die is afgerond (OK) of mislukt. Zie Site-activiteit.

Volgende stappen