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" }
Consider the following static asset to be served by Spin's static file server.
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-encodingcrate successfully returns the file.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