← Cloudflare Workers / workers / cache

Omezení

Tato stránka uvádí scénáře, ve kterých se Workers Caching neuplatňuje, a dále poznámky k tomu, jak souvisí s dalšími cache, které již možná používáte.

Pouze GET a HEAD požadavky jsou ukládány do mezipaměti. POST, PUT, PATCH, DELETE, a další metody vždy váš Worker vyvolají.

GET a HEAD pro stejnou URL sdílejí jeden záznam v cache. HEAD požadavek, který přijde do studené mezipaměti, se převede na GET interně, aby se mezipaměť naplnila celým assetem. Viz Cache keys.

Pokud potřebujete ukládat do mezipaměti odpovědi na neidempotentní požadavky, udělejte to ve Workeru explicitně, například vytvořením hashe těla požadavku do syntetické URL adresy a provedením interního GET subrequest.

Požadavky na upgrade WebSocket (GET hodnotou Upgrade: websocket) obcházejí mezipaměť a vždy vyvolají váš Worker. Relace WebSocket jsou už ze své podstaty stavové, takže nemá smysl je ukládat do mezipaměti.

Pouze fetch() volání na WorkerEntrypoint procházejí přes Workers Caching. Vlastní metody RPC jako ctx.exports.Backend.getUser(id) obejde cache a callee vždy spustí bez ohledu na hodnotu entrypointu cache.enabled nastavení.

Chcete-li kešovat část práce, která je aktuálně vystavena jako metoda RPC, přepracujte ji na fetch handler na vlastním entrypointu a zavolat ho s fetch().

Workers Caching následující odpovědi nikdy neukládá do mezipaměti, a to ani při explicitním Cache-Control direktivy:

• 520-526 (Cloudflare failsafe responses) se považují za dočasné chyby a Worker se pokaždé spustí znovu.
• 206 Partial Content vrácená vaším Workerem se neukládá. Workers Caching očekává, že váš Worker vrátí úplnou 200 odpověď a rozsah si rozděluje sama. Přečtěte si Range požadavky pro podporovaný vzor.

Workers Caching se vztahuje pouze na HTTP požadavky zpracované fetch handler na Vstupní bod Workeru. Následující typy volání se vždy spouští bez zapojení cache:

• Cron Triggers, scheduled invocations via the scheduled handler.
• Queue consumers : zprávy doručené přes queue handler.
• Workflows, workflow step execution.
• Tail Workers, trace event handlers.
• Durable Objects : volání Durable Object se nikdy neukládají do mezipaměti bez ohledu na handler nebo metodu. Pokud chcete ukládat HTTP odpovědi Durable Object do mezipaměti, obalte ho entrypointem Workeru s povoleným ukládáním do mezipaměti. Viz Ukládání odpovědí Durable Object do mezipaměti.

Neexistuje režim "purge by host". Mezipaměť patří Workeru, nikoli doméně, the host is not part of the cache key, so purging by host would not map onto anything the cache stores. Use vymazání podle tagu, vymazání podle prefixu cesty, nebo purgeEverything místo toho.

Neexistuje API pro předběžné naplnění mezipaměti odpověďmi vygenerovanými v době sestavení. Odpověď se do mezipaměti uloží až poté, co byla alespoň jednou obsloužena. Pokud potřebujete mít předrenderovaný obsah k dispozici již pro prvního žadatele, použijte Static Assets.

Limity velikosti odpovědi jsou stejné jako u cache zóny Cloudflare. Limity podle jednotlivých plánů naleznete v Limity velikosti pro ukládání do mezipaměti.

Limity na počet, délku a znakovou sadu Cache-Tag hodnoty jsou stejné jako u Cloudflare zone cache. Viz Limity cache tagů pro úplný seznam.

ctx.cache.purge() používá stejný systém omezování rychlosti jako zone purge API. Protože je ale Workers Caching svázán s Workerem, nikoli se zónou, Workers Caching vždy používá Limity úrovně Free popsané v Dostupnost a limity, bez ohledu na tarif vašeho účtu nebo zóny.

Workers Caching je cache vašeho Workeru, nikoli cache vaší zóny. Jako konfigurační rozhraní slouží samotný Worker, takže vedle něj neexistuje žádná samostatná vrstva pravidel nebo nastavení. Na Workers Caching se nevztahuje nic z následujícího:

Chcete-li ovlivnit cache svého Workeru, upravte svůj Worker. Cache-Control hlavičky, ctx.props, skládání service bindings a ctx.cache.purge() pokrývá rozsah konfigurace.

Cache API je samostatné programové úložiště mezipaměti. Je nezávislé na Workers Caching: operace v jednom neovlivňují druhé a ctx.cache.purge() je to, co invaliduje záznamy Workers-Caching.

U nových Workerů upřednostněte Workers Caching. Cache API je už ze své podstaty nízkoúrovňový primitiv:

• Nefunguje jako read-through cache: odpovědi se do cache ukládají jen tehdy, když je Worker výslovně zavolá pomocí put(), a každý požadavek stále spouští váš Worker při příchodu.
• Neplatí, že by sloučit souběžné požadavky pro stejný prostředek. Nápor provozu na novou URL vyvolá váš Worker jednou za každý požadavek.
• Neúčastní se tiered caching.

Workers Caching poskytuje všechny tři možnosti automaticky. Cache API zůstává užitečné, pokud potřebujete jemně odstupňovanou programovou kontrolu.

Workers Caching je cache na straně serveru před váš Worker. Jde o samostatnou mezipaměť, odlišnou od té, která stojí před odchozími fetch() subrequestů, které váš Worker odesílá na své vlastní origin servery. Oba fungují nezávisle na sobě: fetch() subrequest hit ušetří cestu na váš origin server, zatímco Workers Caching hit ušetří spuštění vašeho Workeru úplně.

cf vlastnosti na Request se v obou případech chovají odlišně:

Následující rozhraní jsou aktuálně ve vývoji:

• Dashboard UI pro povolení ukládání do mezipaměti bez Wrangler.
• Cache Analytics v Workers Observability.