Skip to content

Figure out the right set of cases in error #824

Closed

Description

@lukewagner

Spinning out from this comment, we should discuss what the right set of variant cases are for error. Ideally, we'd be able to align with something in the HTTP spec, but I'm not sure what that is (noting that the well-defined status codes are already in a separate status-code field in responses).

As a general principle, I think it's a good idea to have separate cases only when code might want to actually branch and handle the different cases differently; to convey extra information for debugging purposes we can use the case payloads (e.g., with a string).

Activity

  1. added
    S-inactiveStatus: no discussion in over a year. Records silence during triage; not a proposal to close.
    on Aug 20, 2026
  2. sw17ch commented on Oct 8, 2026

    @sw17ch

    The HTTP champions have looked at the state of this issue in triage. We consider it closed by the current state of the spec (which has significantly expanded the set of error variants).

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-httpS-inactiveStatus: no discussion in over a year. Records silence during triage; not a proposal to close.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions