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
As I've been working with the module fallback service I've found three quirks that I had to workaround (in this patch function).
These are all related to leading /s in paths and I believe could/should be addressed in workerd itself without consumers of the service having to deal with them.
The quirks are:
the referred/specifier paths that workerd provides to the service always start with /, this can be problematic in windows where absolute paths do not start with / (patch)
when returning a redirection (301) result, such needs to start with /, again this is problematic in windows where absolute paths do not start with / (patch)
when returning a module (200) result, the name of the module must not include /, that in my opinion is a bizzare/confusing behavior because in all other cases workerd includes leading /s but in this case it actually refuses paths that start with / (patch)
The text was updated successfully, but these errors were encountered:
As I've been working with the module fallback service I've found three quirks that I had to workaround (in this patch function).
These are all related to leading
/
s in paths and I believe could/should be addressed in workerd itself without consumers of the service having to deal with them.The quirks are:
/
, this can be problematic in windows where absolute paths do not start with/
(patch)/
, again this is problematic in windows where absolute paths do not start with/
(patch)/
, that in my opinion is a bizzare/confusing behavior because in all other cases workerd includes leading/
s but in this case it actually refuses paths that start with/
(patch)The text was updated successfully, but these errors were encountered: