For ein biletrespons som går gjennom ein HTTP-synleg delt cache, publiser ei eksplisitt levetid og ein validør. Når biletet er trygt å bruke på nytt mellom brukarar, er døme på responshovud:

Cache-Control: public, max-age=604800
ETag: "image-v4"

Levetida er i sekund; 604800 er éi veke. Bruk public berre for innhald som er meint å bli brukt på nytt mellom brukarar.

Viss nettlesaren og den delte proxyen treng ulike levetider, gjev s-maxage levetida til den delte cachen. Til dømes gjev max-age=3600 med s-maxage=604800 den delte cachen den lengre ferskleiksperioden.

Expires er ein dato, ikkje ei varigheit

Expires tek eit tidsstempel i HTTP-datoformat. max-age overstyrer feltet, og s-maxage har forrang for delte cachar. Generer kva som helst Expires-dato når responsen blir produsert.

Ei ny innlasting kan be om validering

Ein førespurnad som inneheld Cache-Control: no-cache ber om vellukka validering hjå opphavet før ein lagra respons blir brukt på nytt. Det kan skje sjølv når den vanlege ferskleikspolicyen til responsen elles ville tillate gjenbruk.

Validøren lèt cachen kontrollere eit uendra bilete effektivt. Ein 304-respons kan stadfeste den lagra representasjonen utan å senda biletbyta på nytt frå opphavet. Trafikk til opphavet tyder derfor ikkje i seg sjølv at det cacha objektet er kasta.

Samanlikn normal gjenbruk og eksplisitte nye innlastingar når du går gjennom policyen.

Relaterte artiklar