[bug]: cannot serve Next.js SPA because of percent encoding file path

[radu-matei]

Consider the following static asset to be served by Spin's static file server.

ls assets
20 2 minutes  [templateId]-0fa5d0d4ec6d915f.js

When making a request for this asset, the browser will encode the [] characters, resulting in a request for the following path: /static/%5BtemplateId%5D-0fa5d0d4ec6d915f.js.

However, this request results in a 404 Not Found, since the file server will not attempt to decode the path.

This results in the file server being broken when attempting to serve a static export of a Next.js website single page appliation.

Manually decoding the path using the percent-encoding crate successfully returns the file.

use percent_encoding::percent_decode_str;

#[spin_sdk::http_component]
async fn handle_request(req: IncomingRequest, res_out: ResponseOutparam) {
// 
    let raw_path = req.uri().parse::<Uri>().expect("URI is invalid");
    let trimmed_path = raw_path.path().trim_start_matches('/');
    let path = percent_decode_str(trimmed_path)
        .decode_utf8()
        .unwrap_or_else(|_| trimmed_path.into())
        .into_owned();

However, I am not sure how to handle this safely across all other scenarios.

Until this is addressed, serving Next.js websites is impossible.

In the meantime, I created a branch of the file server that specifically handles this use case -- note this cannot be used as a general purpose replacement, since it breaks other scenarios.

See main...radu-matei:spin-fileserver:feat/path-percent-encoding

[component.ui]
source = { url = "https://raw.githubusercontent.com/radu-matei/spin-fileserver/feat/percent-encoding-bin/spin_static_fs.wasm", digest = "sha256:18751ae2d62554561afe811c59d15b62112ed5eb1b236881d2c1c73968681761" }
files = [{ source = "ui/out", destination = "/" }]
environment = { FALLBACK_PATH = "index.html" }

[lann]

I don't see any problem with the given snippet; percent-encoding should be performed on paths before interpreting. There might be issues with / in some environments but I'm pretty sure it should be fine in WASI where / cannot appear in filenames.

[lann]

It might make sense to disallow .. as a path component - while WASI impls are supposed to prevent traversing out of a mounted directory like that there really isn't much reason to support it.

[lann]

note this cannot be used as a general purpose replacement, since it breaks other scenarios.

Could you say more about this? I guess it could be a backward-incompatible change if someone is currently relying on percent-encoding being preserved but decoding is the "technically correct" thing to do.