Erota sovellus- ja HTTP-välimuisti
Redisillä, Workers KV:llä ja HTTP-välimuisteilla ei automaattisesti ole samoja takuita. Workers KV on lopulta yhtenäinen: kirjoitus ei näy heti kaikkialla. Alla olevat direktiivit koskevat HTTP-välimuistia eivätkä yksin määritä sovellusvälimuistia.
| HTTP-vastauksen direktiivi | Päämerkitys | Raja |
|---|---|---|
| no-cache | Tallennus sallittu, tarkistus ennen uudelleenkäyttöä. | Ei tarkoita tallennuskieltoa. |
| no-store | Älä tallenna tätä vastausta välimuisteihin. | Ei poista aiempia kopioita automaattisesti. |
| private | Ei tallennusta jaettuun välimuistiin. | Ei todennussääntö. |
| max-age | Vastauksen tuoreusaika. | Ei takaa kaikkien tietojen yhtenäisyyttä. |
Testaa oikea vastaus oikealle henkilölle
- Määritä avainvaihtelut resurssin, parametrien, kielen ja oikeuksien mukaan. Testaa, ettei tili saa toisen yksityistä vastausta.
- Määritä enimmäisikä, mitätöinti sekä muutos- ja poistotilanteet. Lyhyt TTL ei takaa heti yhtenäisiä lukuja.
- Testaa samanaikainen vanheneminen, välimuistin ja alkuperän häiriö. Yhdistä päivityksiä tarvittaessa ja tarjoa vanhaa vastausta vain liiketoimintasääntöjen salliessa.
Mittaa muutakin kuin osumaprosenttia
Seuraa viivettä, virheitä, alkuperän kuormaa ja virheellisiä tai vanhoja vastauksia. Saldot, varattu varasto ja oikeudet voivat vaatia eri takuut kuin julkinen luettelo. Nopea välimuisti ei saa olla hallitsematon vaihtoehtoinen totuuslähde.
Alkuperäiset lähteet
API-välimuistin on säilytettävä käyttöoikeuspäätökset.
Vastausvälimuisti voi tehdä virheellisestä kyselystä nopean, kun avaimet jättävät huomiotta pyytäjän käyttöoikeudet. Riski kasvaa, kun graafi yhdistää julkisia ja yksityisiä objekteja.
- Luokittele julkiset, yksityiset ja roolista riippuvat kentät ennen välimuistiin tallentamista.
- Testaa vastaus yhden tilin alaisuudessa ja pyydä sitä toisen tilin alaisuudessa.
- Mitätöi tulokset käyttöoikeuksien tai tietojen muutosten jälkeen.
Ensisijainen lähde: OWASP — GraphQL Cheat Sheet. Aiheeseen liittyvä menetelmä: lue käytännön opas.
Mittaa myös välimuistitiedon ajantasaisuutta
Kuvitteellinen esimerkki: tiedot eivät kuvaa asiakasta tai havaittua tulosta.
Kaksi lukupyyntöä ovat nopeita, mutta toinen näyttää vanhaa saatavuutta vielä lähteen muuttumisen jälkeen.
- Vertaa arvoa, versiota, lukupaikkaa ja muutoksesta kulunutta aikaa. Testaa mitätöinti, vanheneminen ja lähteen käyttö järjestelmäsopimuksen mukaisesti.
- Määritä hyväksyttävä vanhentuneisuus käyttötavoittain ja seuraa eroja. Pienempi viive ei osoita toimitetun tiedon johdonmukaisuutta.
Ensisijainen lähde: IETF — RFC 9111, HTTP Caching. Aiheeseen liittyvä menetelmä: lue käytännön opas.
Hylätyt aliverkkotunnukset: CNAME-viitteen hallittu poisto
Yhdistä DNS-nimet hallittuihin resursseihin ja sulje riippuvuudet ennen resurssin vapautusta.
- Kirjaa nimi, CNAME-ketju, tarjoajan resurssi ja omistaja. Vertaa DNS-vyöhykettä valtuutetun tilin inventaarioon. HTTP-virhe, NXDOMAIN tai puuttuva resurssi vaatii selvityksen, ei todista haltuunoton mahdollisuutta. Suojaukset riippuvat tarjoajasta.
- Poista DNS-viite tai ohjaa se hallittuun kohteeseen ennen resurssin vapautusta. Huomioi aiemmat TTL-arvot ja välimuistit; tarkista auktoritatiivinen DNS ja useita resolvereita. Säilytä tarvittavat omistajuuden vahvistukset äläkä poista kaikkia TXT-tietueita.
- Tarkista linkit, uudelleenohjaukset, OAuth-paluuosoitteet, webhookit ja evästeiden verkkotunnukset. Jos resurssi on jo vapautettu, korjaa DNS ja tutki altistuminen poikkeamaprosessissa. Täsmäytä DNS ja resurssit jokaisen poiston jälkeen.
Toistettava hyväksyntätapaus
Kuvitteellinen esimerkki: tiedot eivät kuvaa asiakasta tai havaittua tulosta.
Näytä tapauksen tiedot
{
"name": "portal.example",
"cname_present": true,
"resource_deleted": true,
"provider_claimability": "not_verified",
"takeover_observed": false,
"expected": "remove_or_replace_mapping_and_review_exposure"
}Odotettu päätös
Kuvitteellinen esimerkki: portal.example osoittaa poistettuun resurssiin. Poista CNAME tai valitse hallittu kohde; puuttuva resurssi ei yksin todista ulkopuolisen haltuunottoa.
Todistaako virhesivu aliverkkotunnuksen haltuunottomahdollisuuden?
Ei. Varmista resurssin tila sekä tarjoajan varaus- ja omistajuussäännöt. Älä varaa resurssia riskin osoittamiseksi.
Ensisijainen lähde: Microsoft — Prevent dangling DNS entries. Aiheeseen liittyvä menetelmä: lue käytännön opas.
ETag, HTTP-välimuisti ja samanaikaiset muutokset
Tämän kieliversion tarkemmat lähdekuvaukset ovat englanniksi.
Revalidation does not replace cache isolation
A matching If-None-Match can justify 304 for the selected representation after access checks. It does not by itself select the correct user variant.
- Separate variant selection, authorisation and validator comparison.
- Test weak and strong tags with If-None-Match: the comparison is weak.
- Read no-cache as validation before reuse, rather than no-store.
Explore ETag comparisons and the simulator →
References reviewed · RFC 9110 · §13 · RFC 9111 · RFC 6585 · §3
GraphQL: virheet, listat ja osittaiset tiedot
Tämän kieliversion tarkemmat lähdekuvaukset ovat englanniksi.
GraphQL result: follow the error path
Aliases belong to the result; list indices start at zero. These details determine where a client should flag missing data.
- Compare absent data, partial data and data: null.
- Keep the original path even when a parent becomes null.
- Test permissions, quotas and interface states separately.
Explore GraphQL responses and nullability →
GraphQL Specification · September 2025 · Published edition · September 2025