HTTP
Cachar HTTP-svar
Sök…
Anmärkningar
Svaren cachas separat för varje URL och varje HTTP-metod.
HTTP-caching definieras i RFC 7234 .
Ordlista
- färskt - cache-svarat tillstånd, som inte har gått ut ännu. Vanligtvis kan ett nytt svar tillfredsställa förfrågningar utan att behöva kontakta den server som svaret härstammar från.
- föråldrat - tillstånd för ett cache-svar, som är förbi dess utgångsdatum. Vanligtvis kan inaktuella svar inte användas för att tillgodose en begäran utan att kontrollera med servern om den fortfarande är giltig.
- tillfredsställa - cache-svar uppfyller en förfrågan när alla villkor i begäran matchar det cachade svaret, t.ex. de har samma HTTP-metod och URL, svaret är färskt eller förfrågan tillåter föråldrade svar, begärande rubriker matchar rubriker listade i svarets
Varyrubrik, etc. . - revalidation - kontrollera om ett cache-svar är färskt. Detta görs vanligtvis med en villkorad begäran som innehåller
If-Modified-SinceellerIf-None-Matchoch svarstatus304. - privat cache - cache för en enda användare, t.ex. i en webbläsare. Privata cacheminne kan lagra personliga svar.
- public cache - cache som delas mellan många användare, t.ex. i en proxyserver. En sådan cache kan skicka samma svar till flera användare.
Cachssvar för alla i 1 år
Cache-Control: public, max-age=31536000
public betyder att svaret är detsamma för alla användare (det innehåller ingen personlig information). max-age är inom några sekunder. 31536000 = 60 * 60 * 24 * 365.
Detta rekommenderas för statiska tillgångar som aldrig är tänkta att förändras.
Cache-personligt svar i 1 minut
Cache-Control: private, max-age=60
private specificerar att svaret bara kan cachelagras för användare som begärde resursen och inte kan återanvändas när andra användare begär samma resurs. Detta är lämpligt för svar som är beroende av kakor.
Sluta använda cachade resurser utan att kontrollera med servern först
Cache-Control: no-cache
Klienten kommer att bete sig som om svaret inte cachades. Detta är lämpligt för resurser som oförutsägbart kan ändras när som helst och som användare alltid måste se i den senaste versionen.
Svaren med no-cache kommer att vara långsammare (hög latens) på grund av behovet av att kontakta servern varje gång de används.
Men för att spara bandbredd, kunderna kan fortfarande lagra sådana svar. Svar med no-cache kommer inte att användas för att uppfylla förfrågningar utan att kontakta servern varje gång för att kontrollera om det cachade svaret kan återanvändas.
Begär svar som inte lagras alls
Cache-control: no-store
Instruerar kunderna att inte cache svaret på något sätt och att glömma det så snart som möjligt.
Detta direktiv designades ursprungligen för känslig information (idag bör HTTPS användas istället), men kan användas för att undvika förorenande cachar med svar som inte kan återanvändas.
Det är lämpligt endast i specifika fall där svarsdata alltid är olika, t.ex. en API-slutpunkt som returnerar ett stort slumpmässigt antal. Annars kan no-cache och revalidering användas för att ha ett "oklandbart" svar, medan du fortfarande kan spara bandbredd.
Föråldrade, redundanta och icke-standardrubriker
Expires- anger datum när resursen blir gammal. Det förlitar sig på att servrar och klienter har exakta klockor och stöder tidszoner korrekt.Cache-control: max-agehar företräde framförExpiresoch är i allmänhet mer tillförlitlig.post-checkochpre-checkdirektiven förlängningar icke-standardiserade Internet Explorer som möjliggör användning av inaktuella svar. Standardalternativet ärstale-while-revalidate.Pragma: no-cache- föråldrad 1999 .Cache-controlbör användas istället.
Ändra cachade resurser
Den enklaste metoden att kringgå cache är att ändra webbadressen. Detta används som bästa praxis när webbadressen innehåller en version eller ett kontrollsumma av resursen, t.ex.
http://example.com/image.png?version=1
http://example.com/image.png?version=2
Dessa två URL: er kommer att cachelagras separat, så även om …?version=1 cachades för alltid , kan en ny kopia omedelbart hämtas som …?version=2 .
Använd inte slumpmässiga webbadresser för att kringgå cachar. Använd Cache-control: no-cache eller Cache-control: no-store istället. Om svar med slumpmässiga webbadresser skickas utan direktivet no-store de onödigt i cacheminnen och skjuter ut mer användbara svar ur cachen, vilket gör nedbrytningen av hela cachen.