-
Notifications
You must be signed in to change notification settings - Fork 207
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 3: Cache API doesn't work from Miniflare service binding #475
Labels
tre
Relating to Miniflare 3
Comments
mrbbot
added a commit
that referenced
this issue
Feb 20, 2023
Previously, the `MF-Custom-Service` header was including on the `request` parameter passed to custom service functions. This usually wasn't a problem, but if the request ever made it back to the loopback server (e.g. via `caches.default.put(request, ...)`), it would be forwarded back to the custom service instead of the appropriate plugin router.
mrbbot
added a commit
that referenced
this issue
Feb 27, 2023
Previously, the `MF-Custom-Service` header was including on the `request` parameter passed to custom service functions. This usually wasn't a problem, but if the request ever made it back to the loopback server (e.g. via `caches.default.put(request, ...)`), it would be forwarded back to the custom service instead of the appropriate plugin router.
mrbbot
added a commit
that referenced
this issue
Feb 27, 2023
Similar to #475, we weren't deleting the `MF-Original-Header` URL from incoming requests, leading to incorrect URLs in the loopback server when the incoming request was passed-through as the cache key. Tests also needed to be updated as the storage location is now based off the actual URL passed to `dispatchFetch()`.
mrbbot
added a commit
that referenced
this issue
Feb 27, 2023
Similar to #475, we weren't deleting the `MF-Original-URL` header from incoming requests, leading to incorrect URLs in the loopback server when the incoming request was passed-through as the cache key. Tests also needed to be updated as the storage location is now based off the actual URL passed to `dispatchFetch()`.
mrbbot
added a commit
that referenced
this issue
Feb 27, 2023
Similar to #475, we weren't deleting the `MF-Original-URL` header from incoming requests, leading to incorrect URLs in the loopback server when the incoming request was passed-through as the cache key. Tests also needed to be updated as the storage location is now based off the actual URL passed to `dispatchFetch()`.
Closed by #515 👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If you have a service binding that then calls into cache, this doesn't work because the request has the wrong MF-Custom-Service set for the service binding but cache uses the same header.
The text was updated successfully, but these errors were encountered: