Russell
CDCloudflare Developers
•Created by Russell on 6/25/2024 in #workers-help
responses with "cf-cache-status: REVALIDATED" are being stored in cache following fetch()
Symptom:
Edge worker consistently responds for some requests with
cf-cache-status: REVALIDATED
and no Age
header. This happens until this resposne falls out of cache. It occurs randomly across various requests.
Detail:
I have an edge worker that is fetch()
ing content from another site which is using cloudflare. Sometimes, a response from the origin has the header cf-cache-status: REVALIDATED
. What appears to happen is that my edge worker appears to store this header in it's own cached response.
Question:
How can I ensure this response has cf-cache-status: HIT
in the cache? As per my other post, this is tiered caching so I don't think I can modify the response and use cache.put()
... Should I manually change it each time in the worker as a cludge? As such?
1 replies
CDCloudflare Developers
•Created by Russell on 6/25/2024 in #workers-help
Managing tiered caching from edge worker after origin response received
Hi!
I have a worker that is making a request via
fetch()
to another resource and returning that response. The worker is acting on a domain (incoming request and origin request) using tiered caching. Sometimes I want to NOT cache that response but only AFTER I have fetched it and checked the response content. I do not want to check the response content every time - only when the cache was not present (MISS or EXPIRED).
Let's assume that I currently cannot determine what in the request is responsible for causing this but I sometimes get a bad (status 200 but content contains erroneous elements) response from the origin.. I do not control this origin. My cf
options object passed to fetch()
are cacheEverything: true
and 'cacheTtlByStatus': {'200-299'}: 12345,
so any 200 response will be cached, even if I later detect that it was bad. I can try to detect the erroneous response but how would I stop this response being stored in cache on this occasion so the next call for this resource doesn't respond with the bad response again? My understanding is that the tiered cache is populated based on the response from fetch()
. Is this accurate?
I understand that without tiered caching, I could if (cache.match(cacheKey))
and then if response = fetch(bla, {cf: { cacheEverything: true, cacheTtl: 12345, cacheKey:'bla'}})
returned bad info, I could cache.delete(cacheKey)
but how does that work with tiered caching? Is there a way to check for match and delete tiered cache responses from within a worker? Or do I have to make an http call to the cache API from within the worker to purge by tag or by cacheKey to ensure it's removed from the tiered cache?1 replies