Disable cache on worker's subrequest

How to disable cache on worker’s subrequest (that is, when you call fetch() )?

Maybe try:

await fetch(request { cf: { cacheTtl: 0 } })

There’s currently no way to bypass cache on a fetch() to a static asset from within worker code. We’re in the process of implementing a way to do so, but in the meantime a workaround is to set a Page Rule for the route in question.

Note that that doesn’t truly bypass the cache – it still checks to see if an asset is cached and returns it if so. It’s only when the asset is not found in the cache that the cacheTtl feature will make a difference. That may be enough for @256462034b’s use case, of course.

1 Like

What’s the status on this feature?

I have code where I’ve used fetch(request, { cf: { cacheTtl: -1 } }) but that appears to be explicitly stated as having no-effect, but only in an older version of the docs, and probably only worked because I also have a Page Rule for the backends I was actually working with that set Cache Level: Bypass, and so I didn’t notice that cacheTtl: -1 did nothing.

What about this approach? Bypassing Cloudflare Cache

I’m afraid it was postponed. We’d still like to do it, but I don’t know when it would happen. In the meantime, the best suggestion I can offer is to use a Bypass Cache page rule on the routes in question. You can selectively override the page rule with a cacheEverything or cacheTtl property on the fetch’s cf blob.

Negative values on cacheTtl don’t have a well-defined meaning that I’m aware of. In practice, they appear to have a roughly similar effect as cacheTtl: 0: check the cache, but store the response with an expiration time in the past. The main difference between cacheTtl: <negative value> and cacheTtl: 0 is that cacheTtl: 0 only applies to 200, 206, and 301 responses (most other response statuses get a default TTL, currently 5 minutes). I would advise not relying on negative cacheTtl values for any specific behavior, though, as the behavior may change.

A fetch() with a negative cacheTtlByStatus dictionary value will still check the cache, but the response will not be stored. The difference in behavior between this and cacheTtl: 0 is that, assuming an empty cache, a second cacheTtl: 0 response will have CF-Cache-Status: EXPIRED, whereas a second cacheTtlByStatus: { <status range>: 0 } will have CF-Cache-Status: MISS.

Negative cacheTtlByStatus values are a bit more officially supported, but they still do not bypass the cache in a strict sense of the term. If there’s an existing response in cache, it will be returned. Additionally, Railgun won’t work, range requests won’t be forwarded to the origin, a Vary header will be added, etc.

I realize the behavior is rather confusing – trying to make sense of it is why I took a while to respond. My definite recommendation remains to use a Bypass Cache page rule if you need to bypass the cache.



Hi @Herris, can I use Bypass Cache page rule if I just use the free workers?
If I add my site but not actually changing my ns records, can I still set those page rules?

Just replying here, as I recently found that the cacheTtl setting now DOES accept a negative value as per https://developers.cloudflare.com/workers/examples/cache-using-fetch#ttl-interpretation

I got into trouble setting the cacheTtl to 0 fetch(request, { cf: { cacheTtl: 0 } }) as it resulted in cookies being stripped from the request, which was not the intention. But changing to -1 results in the expected behavior of not caching and not “losing” cookies: fetch(request, { cf: { cacheTtl: -1 } }).

Hope this helps others finding this thread :slight_smile:


Note: This feature is available only to enterprise customers.


Thanks for the heads up!

Why not adding a timestamp param to the request URL?