WASIp3 HTTP request path-and-query is more lenient than RFC 3986

[wingo]

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; WebAssembly/wasi-http#178 (comment).

[bjorn3]

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:

https://github.com/hyperium/http/blob/439d1c50d71e3be3204b6c4a1bf2255ed78e1f93/src/uri/path.rs#L62-L73

[tschneidereit]

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.)

[wingo]

FWIW, @lukewagner is saying in WebAssembly/wasi-http#178 (comment) 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.

[wingo]

that comment in the http crate is delightful :)

[wingo]

Regarding the URL WhatWG spec -- I don't think it's the right reference for WASI. Otherwise wasi:http would 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 :)