Skip to content

[v0.3] Specify what is meant by "not syntactically valid" #791

Open

Description

@wingo

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?

Activity

  1. pchickey commented on Aug 29, 2025

    @pchickey
    Contributor

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

  2. lukewagner commented on Aug 29, 2025

    @lukewagner
    Member

    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.

  3. wingo commented on Oct 2, 2025

    @wingo
    ContributorAuthor

    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.

  4. wingo commented on Oct 2, 2025

    @wingo
    ContributorAuthor

    Should we check that percent-encoding is valid? I would guess not, but we could require that the user do so.

  5. wingo commented on Oct 2, 2025

    @wingo
    ContributorAuthor

    For path-and-query, #780 is a related issue.

  6. wingo commented on Oct 2, 2025

    @wingo
    ContributorAuthor

    For path-and-query, do we forbid fragments? Wasmtime currently accepts # in a path-and-query.

  7. pchickey commented on Oct 2, 2025

    @pchickey
    Contributor

    Not sure if we should forbid fragments or if we permit them to be normalized away. What does whatwg fetch do with a fragment?

  8. lann commented on Oct 3, 2025

    @lann
    Contributor

    What does whatwg fetch do with a fragment?

    Fragments are permitted and removed for requests.

  9. wingo commented on Feb 20, 2026

    @wingo
    ContributorAuthor

    The web-compatible thing to do seems to be to allow raw UTF-8 in the path/query: hyperium/http#715

  10. xia-chao commented on Oct 24, 2026

    @xia-chao

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P-httpProposal: wasi-http

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions