You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add support for static routing to Workers Assets (#9416)
* WC-3583 Add static routing matching to rules engine
* WC-3583 Support static routing in router config
* WC-3583 Route requests based on static routing when present
- When a request matches a static routing "exclude" rule, it's directly
forwarded to the asset worker.
- When a request matches a static routing "include" rule, it's directly
forwarded to the user worker.
- Otherwise, previous behavior takes over
This also adds a new analytics field (double6) for what routing decision
was made
* WC-3583 Fix unawaited async assertion
vitest yelled at me and told me this should be awaited and may error in
future releases
* WC-3583 Disable Sec-Fetch-Mode check when static routing is present
When the Router worker has static routing, the check against
"Sec-Fetch-Mode: navigate" is unnecessary. We have explicit static
routing to indicate whether or not we should go to a User worker or
the Asset worker, and should not try and guess via usually-set browser
headers
This adds a new parameter to unstable_canFetch RPC method, which should
be fine for backwards compatibility, and can be extended in the future
if needed. This was necessary because the Asset worker checks the
Request headers for Sec-Fetch-Mode to indicate if it can serve an asset
(including an index.html or 404.html page based on not_found_handling),
but static routing is only provided to the Router worker. Thus, we need
to pass more information over RPC
* WC-3583 Add changeset
* WC-3583 Update static routing for run_worker_first based configuration
Now that we're not providing this configuration via _routes.json, we can
relax some of the configuration. Much of this happens on the backend,
but some field names have been changed ("include" -> "worker",
"exclude"->"asset")
---------
Co-authored-by: Carmen Popoviciu <[email protected]>
Implements the proposal noted here https://github.com/cloudflare/workers-sdk/discussions/9143
8
+
9
+
In brief: when static routing is present for a Worker with assets, routing via those static rules takes precedence. When a request is evaluated in the Router Worker, the request path is first compared to the `"asset_worker"` rules (which are to be specified via "negative" rules, e.g. `"!/api/assets"`). If any match, the request is forwarded directly to the Asset Worker. If instead any `"user_worker"` rules match, the request is forwarded directly to the User Worker. If neither match (or static routing was not provided), the existing behavior takes over.
10
+
11
+
As part of this explicit routing, when static routing is present, the check against `Sec-Fetch-Mode: navigate` (to determine if this should serve an asset or go to the User Worker for not_found_handling) is disabled. Routing can be controlled by setting routing rules via `assets.run_worker_first` in your Wrangler configuration file.
0 commit comments