Wasmtime GitHub notifications bot (Oct 02 2025 at 09:38): Wasmtime GitHub notifications bot (Oct 02 2025 at 09:38):wingo opened issue #11779:
According to RFC 3986 §3.3, the following predicate should define the valid characters in a path:
fn is_valid_path_char(ch: char) -> bool { // pchar = unreserved / pct-encoded / sub-delims / ":" / "@" ch.is_ascii_alphanumeric() || "-._~".contains(ch) // unreserved || ch == '%' // pct-encoded || "!$&'()*+,;=".contains(ch) // sub-delims || ":@".contains(ch) }However, the following paths are accepted via
request.set_path_and_query:
/"/{/|/}/^/[/]/\/#What should change here, the spec or Wasmtime?
Relatedly, Wasmtime accepts non-absolute paths, which I am not sure are valid; https://github.com/WebAssembly/wasi-http/issues/178#issuecomment-3359974132.
Wasmtime GitHub notifications bot (Oct 02 2025 at 09:38):wingo added the bug label to Issue #11779.
Wasmtime GitHub notifications bot (Oct 02 2025 at 09:41):wingo edited issue #11779:
According to RFC 3986 §3.3, the following predicate should define the valid characters in a path component (besides the
/and?delimiters):fn is_valid_path_char(ch: char) -> bool { // pchar = unreserved / pct-encoded / sub-delims / ":" / "@" ch.is_ascii_alphanumeric() || "-._~".contains(ch) // unreserved || ch == '%' // pct-encoded || "!$&'()*+,;=".contains(ch) // sub-delims || ":@".contains(ch) }However, the following paths are accepted via
request.set_path_and_query:
/"/{/|/}/^/[/]/\/#What should change here, the spec or Wasmtime?
Relatedly, Wasmtime accepts non-absolute paths, which I am not sure are valid; https://github.com/WebAssembly/wasi-http/issues/178#issuecomment-3359974132.
Wasmtime GitHub notifications bot (Oct 02 2025 at 09:44):wingo edited issue #11779:
According to RFC 3986 §3.3, the following predicate should define the valid characters in a path component (besides the
/and?delimiters):fn is_valid_path_char(ch: char) -> bool { // pchar = unreserved / pct-encoded / sub-delims / ":" / "@" ch.is_ascii_alphanumeric() || "-._~".contains(ch) // unreserved || ch == '%' // pct-encoded || "!$&'()*+,;=".contains(ch) // sub-delims || ":@".contains(ch) }However, the following paths are accepted via
request.set_path_and_query:
/"/{/|/}/^/[/]/\/#What should change here, the spec or Wasmtime?
Relatedly, Wasmtime accepts non-absolute paths, which I am not sure are valid; https://github.com/WebAssembly/wasi-http/issues/178#issuecomment-3359974132.
Wasmtime GitHub notifications bot (Oct 02 2025 at 10:02):bjorn3 commented on issue #11779:
I think the http crate is following https://url.spec.whatwg.org/, which is a formalization of how actual browsers behave in practice. Also for
",{and}see:
Wasmtime GitHub notifications bot (Oct 02 2025 at 10:15):tschneidereit commented on issue #11779:
As @bjorn3 says, this follows what browsers do, because the RFC isn't web compatible.
Relatedly, Wasmtime accepts non-absolute paths, which I am not sure are valid; WebAssembly/wasi-http#178 (comment).
I think this is a bit underspecified, yeah. It's useful in practice for hosts that route traffic based on patterns that don't just include the host, but also other aspects of the URL: in such a case, it can make sense to interpret relative URLs as relative to the incoming request's URL. At the very least, changing this might be a breaking change at this point (though I'm not certain it is.)
Wasmtime GitHub notifications bot (Oct 02 2025 at 12:02):wingo commented on issue #11779:
FWIW, @lukewagner is saying in https://github.com/WebAssembly/wasi-http/issues/178#issuecomment-3238221648 that at least some parts of RFC 9110 are web-compatible. I don't have a horse in this race, I just want things to be specified somewhere. Could be an RFC, could be a whatwg spec, could have some WASI-specific exceptions, but they should be written down.
Wasmtime GitHub notifications bot (Oct 02 2025 at 12:16):wingo commented on issue #11779:
that comment in the http crate is delightful :)
Wasmtime GitHub notifications bot (Oct 02 2025 at 12:20):wingo commented on issue #11779:
Regarding the URL WhatWG spec -- I don't think it's the right reference for WASI. Otherwise
wasi:httpwould allow spaces in URIs and perform percent-encoding/decoding, but it does not, and that is fine.
Wasmtime GitHub notifications bot (Oct 02 2025 at 12:21):wingo edited a comment on issue #11779:
Regarding the URL WhatWG spec -- I don't think it's the right reference for WASI. Otherwise
wasi:httpwould allow spaces in URIs and perform percent-encoding/decoding, but it does not, and that is fine. I am happy to be corrected of course :)
Wasmtime GitHub notifications bot (Oct 02 2025 at 14:26):alexcrichton added the wasi:impl label to Issue #11779.
Wasmtime GitHub notifications bot (Nov 25 2025 at 14:37):ricochet edited issue #11779:
According to RFC 3986 §3.3, the following predicate should define the valid characters in a path component (besides the
/and?delimiters):fn is_valid_path_char(ch: char) -> bool { // pchar = unreserved / pct-encoded / sub-delims / ":" / "@" ch.is_ascii_alphanumeric() || "-._~".contains(ch) // unreserved || ch == '%' // pct-encoded || "!$&'()*+,;=".contains(ch) // sub-delims || ":@".contains(ch) }However, the following paths are accepted via
request.set_path_and_query:
/"/{/|/}/^/[/]/\/#What should change here, the spec or Wasmtime?
Relatedly, Wasmtime accepts non-absolute paths, which I am not sure are valid; https://github.com/WebAssembly/WASI/issues/791#issuecomment-3359974132.
Last updated: Dec 06 2025 at 07:03 UTC