Open giac-mysten opened 1 month ago
If we go with wildcard paths, we should probably use a syntax similar to nginx rewrite rules
As for the con, we don't enforce that there are no conflicting wildcard paths, we just define that we will process rules in order and go to the first match. later, we can use a trie.
At the moment, HTML5-based routing probably does not work, because the routing of Walrus Sites requires an exact match of the URL path on the list of paths that are in the Sui object for the site.
A bit of design may be needed, but this would be great to enable existing JS tooling to be used with walrus sites.
Designs
Another default
404.html
Currently, if the portal/SW do not find a path, they revert to
/404.html
if it exists.https://github.com/MystenLabs/walrus-sites/blob/9aad845f30a1e33f0aa4998c6b8a54b84f63b232/portal/src/walrus-sites-sw.ts#L287-L293
As a first step, we may want to allow setting a
/walrus-sites-default.html
, which, if it exists, gets loaded when no other path is found.Pros:
Cons:
Contract-side defaults
We could achieve something similar to the above, but without special files, by adding a field in the
Site
object on chain that specifies the default Resource for the sitePros / cons :
Wildcard paths
One possible solution would be to allow "wildcard" paths for resources. I.e.,
/view/*
points to blob idasdf...
, so that the root of the path determines what resources are loaded, and within those resources there is the code to interpret the rest of the url.Pros:
Cons: