Dthere actually was one edge case where I realized that was possible with code I've written 
(not exposed anymore, so people creeping the channel, please don't waste your time).
(not exposed anymore, so people creeping the channel, please don't waste your time).
Elol
EIts a layered security model
EAll good
Dyes, it makes at least two requests though. Sometimes 1 is cached, sometimes 2 are cached, and sometimes 0 are cached.
EI assume the response to the client is derived from the response obejct of one of those? Because thats probably where the hit is coming from, and then it just gets passed back through and we're like oh okay thats a hit somehow
Dcorrect.
EThe cache logic doesn't run in front of the worker, it runs inside the worker based on your subrequests, so you can technically return hit to a POST as long as the subrequest (which is where cache logic happens) is a GET
Dis it because I'm returning a response with a
cf-cache-status header?Dif so, I'm surprised that's trusted, since it's provided by me and starts with
cf-EThere is also a really sneaky workaround with the cache api to cache a POST subrequest https://developers.cloudflare.com/workers/examples/cache-post-request/
but not possible with native fetch cache
but not possible with native fetch cache
EYeah
EIts stripped if the external server tries to inject one, but your Worker can (mostly) do whatever it wants. I'm fairly sure you can edit that to MISS and make cache analytics become very misleading
ERealistically all it impacts is your logs and analytics as well as what the client sees, the actual cache logic doesnt care about it
Dyeah, I do that in some of our Workers; in this case, going through the native fetch is better, because this is what happens if there's a cache miss:
- first subrequest goes through cache api, cache miss
- second subrequest goes through fetch
- first subrequest goes through fetch, cache miss or hit, still only 1 subrequest
EAlso native fetch cache will support tiered cache so bonus hit rate
Dah yes, that brings up another question! For my use-case, caching S3 subrequests to a single Backblaze, do these tier cache settings make sense?
Dand how can I confirm if tiered caching is actually doing anything?
EIf your goal is to minimise requests to Backblaze then yes thats perfect. If your goal was to minimise global response times and you had a ton of traffic from all around the world then Generic might be slightly better.
Dit's the former, ty!
ECacheTieredFill in logs will tell you whether it was used for a given request, you may need to inspect logs over an extended period before you find one because if you keep hitting the same colo its just going to serve from local colo cacheEsome ent customers will use logpush to send to data visualisation software and then graph the tiered cache fills over time
Dahhh neat, I see it now!
Dso right now I am running a script locally that's hitting my Worker (that does requests to B2's S3 API).
The Worker is running in MIA because that's the closest to me; when another service (i.e. Google Cloud Run) in IAD requests the same URL that was cached by my requests, will it:
The Worker is running in MIA because that's the closest to me; when another service (i.e. Google Cloud Run) in IAD requests the same URL that was cached by my requests, will it:
- Pull the MIA cache to IAD
- Not use the MIA cache at all, instead going to origin and saving that in IAD
- Something else?
EIt depends on what toplogy its using (which for smart is dynamically determined), I couldnt speak to it with any certainty
EBut if MIA was one of the colos in the toplogy and it was working optimally then yes it would pull it
EYou may also see in logs a
UpperTierColoID which will tell you which other colo the cache was fetched from, if not the local oneDThis is B2's IP. So does that mean my requests are already being cached in IAD?
EYeah. IAD will store cache and other colos will request copies from IAD if they dont have any locally
EA generic topology would store the cache in more places but would need more origin requests in order to fill them
EAlso worth noting since you have regional tier enabled its a lot more nuanced than that, theres various tiers in the middle before it gets to IAD
Eas a simplified example if you hit a colo on the west coast of the US and it didnt have cache but a regional tier on the west coast did, it can avoid a request to IAD all the way over in the east by taking it from that nearby regional tier
Ewhich keeps latency down
ESmart + Regional is a very powerful combination if your goal is to maximise cache hit rate
Dnice! from what you described, sounds like I'm worrying bout nothing 
DIs there really no way to detect if something is or isn't a Worker subrequest?
EI mean I would have expected
cf.worker.upstream_zone to be supported but if it isnt then noEThat property exists to be used in lieu of cf-worker
DAnother question! If I set
"Cache-Control": "no-cache, no-store, no-transform" on my fetch request in a Worker, will that bypass the Cache Rules?DWhat logic triggers this? I have a setTimeout used for polling that increases on every attempt.
KMost of the errors around scripts never returning a response or promises never completing means there’s stuff being used in the global scope
KThe runtime can only see what was created in that request - so if Request B is depending on a global Promise from Request A then it sees that nothing is left in Request B yet it hasn’t returned a response.
KThat’s usually a different error though, “script will never return a response” or similar.
Dodd... I added some more logging, maybe I missed a throw or something on my promise.
Ddidn't think I had anything in my globals that would cause it
KI guess a theoretical downside that isn’t specific to S3 or R2 is that you might lose Content-Length if on-the-fly decompression is needed.
KIf you don’t need that header then it’s fine.
DCould it be a OOM error somehow?
Dactually I can test this, gonna try the same request on wrangler locally
