Kies voor een bewerkbaar publiek document revalidatie wanneer lezers actuele inhoud moeten krijgen terwijl ongewijzigde pagina's herbruikbaar blijven. Kies no-store wanneer uw publicatievereiste specifiek uitsluit dat HTTP-caches de reactie opslaan.

Deze gids is voor iemand die een publiek document beheert vanaf een Mac-desktop. De taak is een reactiebeleid kiezen en dit controleren in Terminal met een synthetische pagina die alleen neutrale tekst bevat, zoals "Vormgids, versie één". U hebt een testpagina en toegang tot de hostingconfiguratie nodig, of een provider die de reactieheaders kan configureren.

Welk cachebeleid past bij het document?

Begin met de publicatievereiste. Moet de pagina voor elk hergebruik gecontroleerd worden, mag een bestaande kopie gedurende korte tijd bruikbaar blijven, of moeten HTTP-caches de reactie niet opslaan? Dit zijn verschillende vereisten volgens RFC 9111: HTTP Caching.

Publicatievereiste Kandidaat-reactieheader Betekenis voor een HTTP-cache
Controleer vóór elk hergebruik Cache-Control: no-cache Opslag is toegestaan; hergebruik vereist succesvolle validatie.
Stel een kort verlooptijdvenster in Cache-Control: max-age=300, must-revalidate Hergebruik is toegestaan zolang het vers is; eenmaal verouderd is succesvolle validatie vereist.
Sluit reactieopslag uit Cache-Control: no-store De cache mag de reactie niet opslaan of gebruiken voor een ander verzoek.

Het vijfminutenvenster is een illustratierecht, geen aanbevolen standaard. Selecteer dit alleen als uw document die herbruikinterval kan verdragen. must-revalidate alleen vereist geen controle zolang een reactie vers is. Deze onderschijnvolgen RFC 9111's reactierichtlijnen.

Voor de synthetische vormgids: stel een correctie van "drie voorbeelden" naar "vier voorbeelden" moet bij de volgende opvraging gecontroleerd worden. Begin met no-cache en een werkende validator. Als uw vereiste juist zegt dat HTTP-caches deze documentreactie niet mogen bewaren, selecteer no-store. Frequent bewerken, op zich, stelt niet vast dat opslag uitgesloten moet zijn.

Schrijf de vereiste op voordat u instellingen wijzigt: "Controleer het document vóór hergebruik", bijvoorbeeld. Dit geeft u een concrete acceptatiecriterium en voorkomt dat de naam van een instelling het beleid bepaalt.

Wat maakt revalidatie mogelijk?

Een validator identificeert de versie die de client al heeft ontvangen. Een ETag levert een entiteitstag; Last-Modified levert een wijzigingstijdstempel. RFC 9110 beveelt aan beschikbare validators te sturen voor succesvolle documentophaaloperaties, met voorkeur voor zowel een sterke entiteitstag als een wijzigingsdatum. Zie HTTP Semantics, validators en 200 OK.

Dit zijn illustratieve reactieheader-velden, geen serverconfiguratiecode. Ze gaan ervan uit dat de reactiebody de synthetische vormgids is:

Cache-Control: no-cache
ETag: "shape-guide-v1"

Bij een later verzoek kan een client If-None-Match: \"shape-guide-v1\" sturen. Als die tag nog overeenkomt met de geselecteerde representatie, ontvangt het conditionele GET 304 Not Modified, zonder reactiebody. Als het niet meer overeenkomt, kan normale verwerking het gewijzigde document retourneren. De regels staan in RFC 9110's conditionele-verzoeksectie.

De implementatievereiste is dat de validator de documentversie volgt. Kopieer de illustratiere tag niet in een permanente configuratie en laat deze ongewijzigd na bewerkingen. Vraag uw hostingsysteem om validators consistent te genereren en inkomende voorwaarden te evalueren.

Hoeveel kan een ongewijzigde reactie vermijden te overdragen?

Overweeg een expliciet illustratierekenvoorbeeld: een documentbody is 80.000 bytes, en een client haalt het 100 keer op zonder enige bewerkingen. Één volledige reactie gevolgd door 99 succesvolle validaties overdraagt 80.000 body-bytes in plaats van 8.000.000 body-bytes — een verschil van 7.920.000 bytes.

Deze berekening sluit headers, compressie, verbindingsoverhead en eventueel toepassingswerk uit. Het beschrijft alleen body-overdracht. Google's HTTP-caching-uitleg beschrijft dezelfde uitwisseling: een overeenkomende validator toestaat een bodyloze 304, en de client gebruikt de eerder ontvangen inhoud. De daadwerkelijke besparing hangt af van hoe vaak documenten veranderen en hoe clients verzoeken doen.

Waar moet u het beleid configureren?

Configureer de HTTP-reactie die gegenereerd wordt door uw hostingservice, server of content-delivery-laag. De header-voorbeelden bovenaan beschrijven het vereiste resultaat; het zijn geen universele commando's voor een publicatieplatform.

Als uw editor u alleen toestaat documenttekst te wijzigen, biedt een markup-omzeiling geen equivalente controle. De WHATWG HTML-standaard definieert Cache-Control niet als een ondersteunde http-equiv pragma, en legt uit dat deze pragmas grotendeels gescheiden zijn van HTTP-headers. Zie HTML Standard: Pragma directives.

De ondersteunde weg is het gebruik van de gedocumenteerde reactieheader-configuratie van uw host of de provider vragen het te implementeren. Google's crawler-overzicht wijst publiceerders ook naar hun hosting- of contentmanagement-provider voor HTTP-caching-implementatie. Een nuttig verzoek noemt het document, gekozen beleid en validatorgedrag, en vraagt hoe de geleverde reactie geverifieerd kan worden.

Het wijzigen van een JavaScript-verzoekoptie heeft een smaller bereik. WHATWG definieert een Fetch no-store cache-modus die zich gedraagt alsof er geen HTTP-cache is, terwyl no-cache een conditioneel verzoek doet wanneer een geschikte gecachte reactie bestaat. Deze modi regelen dat verzoek; het instellen van een modus in een script configureert niet het serverreactiebeleid van het document. Zie de Fetch Standard's cache modes.

Hoe kunt u revalidatie testen vanaf een Mac?

Gebruik een synthetisch publiek testdocument dat u kunt bewerken. Voordat u begint, maak de inhoud "Vormgids, versie één" en zorg dat de gekozen reactieheaders worden geleverd. Houd deze test gescheiden van echte documentinhoud zodat u een duidelijke, omkeerbare wijziging kunt maken.

Open Terminal en voer de volgende commando's uit in dezelfde sessie. Ze vragen om uw daadwerkelijke test-URL en de validator die door die pagina wordt geretourneerd; geen voorbeeldadres wordt verondersteld. Stop na het eerste verzoek als het mislukt, omleidt of iets anders retourneert dan de beoogde documentreactie.

printf '%s\n' 'Paste the full URL of your synthetic public test page:'
IFS= read -r page_url

curl --silent --show-error --connect-timeout 5 --max-time 20 \
  --dump-header - --output /dev/null --url "$page_url"

printf '%s\n' 'Paste its ETag value exactly, including quotes:'
IFS= read -r page_etag

check_page() {
  curl --silent --show-error --connect-timeout 5 --max-time 20 \
    --dump-header - --output /dev/null \
    --header "If-None-Match: $page_etag" --url "$page_url"
}

check_page

De commando's maken GET verzoeken, tonen ontvangen headers en gooien de reactiebody bewust weg. De timeouts beperken verbindings- en overdrachtstijd; fouten blijven zichtbaar. Deze opties gedocumenteerd in de curl handleiding. Het eerste verzoek zou uw gekozen Cache-Control-waarde en een ETag moeten tonen. Als geen tag aanwezig is, voer dan geen gefabriceerde waarde in: los eerst validatorondersteuning op.

Kopieer de complete tagwaarde, inclusief omringende aanhalingstekens en eventuele W/ prefix. Met een ongewijzigde overeenkomende representatie zou het conditionele verzoek 304 moeten retourneren. Een 304 mag geen inhoud bevatten en moet gespecificeerde metadata bevatten die de equivalente 200 reactie zou vergezellen, inclusief ETag en Cache-Control waar van toepassing. Zie RFC 9110: 304 Not Modified.

Test een bewerking terwijl de oude validator behouden blijft

Wijzig het synthetische document in "Vormgids, versie twee: vier voorbeelden." Nadat de update uw testpagina bereikt, houd de oude tag in dezelfde Terminal-sessie en voer dit vervolgcommando uit:

check_page

Voor dit bewust gewijzigde document, verwacht de nieuwe body beschikbaar te zijn via een normale succesvolle reactie en een bijgewerkte validator. Vervolgens herhaal de initiële commando's met de nieuwe tag en controleer de ongewijzigde versie opnieuw. Dit test beide takken: een wijziging herkennen en geen wijziging herkennen.

Waarneming Volgende diagnostische stap
Initiële reactie geeft een omleiding Gebruik de eind-URL van het document en start de test opnieuw.
Ongewijzigd conditioneel verzoek geeft 200 Controleer of u de tag correct gekopieerd hebt en of conditionele verwerking ingeschakeld is.
Een bewuste inhoudswijziging levert nog steeds 304 op met de oude tag Onderzoek update-levering en validator-generatie voordat u vertrouwt op revalidatie.
Geleverd beleid verschilt van uw configuratie Inspecteer de hosting- en leveringsinstellingen verantwoordelijk voor de uiteindelijke reactie.
Verzoek loopt vast of mislukt Los de ophaalfout op voordat u cachegedrag interpreteert.

Dit zijn diagnostische aanwijzingen, geen bewijs van een specifieke oorzaak. De procedure test de reactie en conditionele uitwisseling; het stelt niet vast hoe elke browser zich gedraagt. Bij het evalueren van no-store, inspecteer die reactierichtlijn direct. Een handmatig samengesteld conditioneel verzoek is geen test van of een browser een reactie heeft opgeslagen.

Wat betekent dit voor Google Search?

Google's huidige crawlerdocumentatie ondersteunt ETag met If-None-Match en Last-Modified met If-Modified-Since. Het beveelt ETag aan voor Google's crawlers en stelt dat afzonderlijke crawlers caching verschillend kunnen gebruiken. Zie Overzicht van Google crawlers en fetchers.

Die pagina zegt ook dat andere HTTP-cachingrichtlijnen niet ondersteund worden, terwijl apart max-age suggereert als mogelijke herindexeringshint naast Last-Modified. Gegeven die gedocumenteerde grens, ga niet ervan uit dat uw browser-georiënteerde no-store of no-cache beleid Googlebot's ophaalschema dicteert. Implementeer en test validators als het gedocumenteerde conditionele-ophalingspad.

Google legt uit dat een 304 ongewijzigde inhoud signaleert aan de verwerkingssystemen; voor Search heeft het verder geen effect op indexeren. Een succesvolle 200 garandeert ook geen indexering. Deze staan gedocumenteerd in Hoe HTTP-statuscodes Google's crawlers beïnvloeden.

Kies het beleid dat overeenkomt met uw documentvereiste, en bewaar het testbewijs: de initiële reactie, een ongewijzigde conditionele reactie en een reactie na een bewuste bewerking. Voor een publiek document dat een controle vóór hergebruik nodig heeft, is revalidatie een praktisch startpunt. Selecteer no-store wanneer het uitsluiten van HTTP-cacheopslag zelf de vereiste is.

Bronnen