You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[v0.3] Specify what is meant by "not syntactically valid" #791
A number of the interfaces that turn strings into typed values, e.g. fields.from-list, fields.set, request.set-method, and so on can return a failure result if the value being set is not "syntactically valid". However, the specification does not define what this means. Suggest adding wording such as, "Syntactically valid methods are defined in RFC 9110§9.1".
Also, is it an error if a WASI HTTP implementation does not impose syntactic constraints on header/method/etc values?
Yes we should amend the spec to clarify in that way, and yes the implementation should not be spec compliant if it fails to impose those constraints (so word it as a MUST).
Agreed this should be added. IIUC, the relevant grammatical rules are field-name (RFC 9110§5.1) and field-value (RFC 9110§5.5) and, thankfully, these grammars are actually real world Web compatible.
For path-and-query, what is the syntax for the path part? Is it path-abempty as mentioned in RFC9110 §4.2.1? That would require that the path start with /, which doesn't seem to be what Wasmtime currently implements.
Quick note from measuring (p2/p3): method, field-name, field-value match RFC 9110; path-and-query match WHATWG URL (raw UTF-8 allowed, # drops the fragment); schemes should match RFC 3986, I think.
Proposal: add a MUST-reject clause to say that.
Note: wasmtime currently accepts invalid schemes today.
Activity
pchickey commentedon Aug 29, 2025
Yes we should amend the spec to clarify in that way, and yes the implementation should not be spec compliant if it fails to impose those constraints (so word it as a MUST).
lukewagner commentedon Aug 29, 2025
Agreed this should be added. IIUC, the relevant grammatical rules are
field-name(RFC 9110§5.1) andfield-value(RFC 9110§5.5) and, thankfully, these grammars are actually real world Web compatible.wingo commentedon Oct 2, 2025
For
path-and-query, what is the syntax for the path part? Is itpath-abemptyas mentioned in RFC9110 §4.2.1? That would require that the path start with/, which doesn't seem to be what Wasmtime currently implements.wingo commentedon Oct 2, 2025
Should we check that percent-encoding is valid? I would guess not, but we could require that the user do so.
wingo commentedon Oct 2, 2025
For path-and-query, #780 is a related issue.
wingo commentedon Oct 2, 2025
For path-and-query, do we forbid fragments? Wasmtime currently accepts
#in a path-and-query.pchickey commentedon Oct 2, 2025
Not sure if we should forbid fragments or if we permit them to be normalized away. What does whatwg fetch do with a fragment?
lann commentedon Oct 3, 2025
Fragments are permitted and removed for requests.
wingo commentedon Feb 20, 2026
The web-compatible thing to do seems to be to allow raw UTF-8 in the path/query: hyperium/http#715
xia-chao commentedon Oct 24, 2026
Quick note from measuring (p2/p3): method, field-name, field-value match RFC 9110; path-and-query match WHATWG URL (raw UTF-8 allowed, # drops the fragment); schemes should match RFC 3986, I think.
Proposal: add a MUST-reject clause to say that.
Note: wasmtime currently accepts invalid schemes today.