-
Notifications
You must be signed in to change notification settings - Fork 672
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Miniflare] caching implementation differs from actual #4390
Comments
Hey! 👋 Thanks for raising this. What is the correct behaviour here? Would it be ok for Miniflare to treat |
Rewriting it on the way in would certainly make it cacheable, but I'm not sure how to go about ensuring that the response when matched/retrieved from the cache was a 429 again (or maybe that would just work?). |
This would only be changing the status passed to |
Sweet, then it sounds like that should do the right thing. |
We also just hit this when writing tests. Cloudflare is able to cache 401 responses, while miniflare will refuse to cache those calls, which makes it not possible to test this use case. Is there a workaround available? |
Hey! 👋 Thanks for raising this issue. I'm going to transfer this to |
When looking into leveraging miniflare for our worker script, we noticed that the caching implemented within miniflare is different from the cache api in workers. Because miniflare leverages "http-cache-semantics" (which cloudworker also uses for its cache implementation), 429s are explicitly not cacheable. This stems from the
storable
call here, which is defined here. The check againstunderstoodStatuses
here and defined here will decide that a 429 is not storable and not cacheable, when the actual worker does allow caching of 429s.Since http-cache-semantics is adhering to the RFC (and based on kornelski/http-cache-semantics#31 they aren't very open to changing which status codes are cacheable), it seems like if miniflare is going to use http-cache-semantics it might need to override the
storable
method?The text was updated successfully, but these errors were encountered: