Add http-response-status-invalid error code#104
Add http-response-status-invalid error code#104acfoltzer wants to merge 1 commit intoWebAssembly:mainfrom
http-response-status-invalid error code#104Conversation
I failed to notice this was missing in WebAssembly#52. Status codes outside the range of 100-599 are [invalid](https://www.rfc-editor.org/rfc/rfc9110#section-15-6), though there is a nod to implementation-defined behavior outside those valid ranges. In practice we have found it very useful to return error codes specific to status problems to customers since our platform does not support codes outside this range, and the next-best option in the RFC 9209 equivalents is the generic `http-protocol-error` which doesn't help a user much with debugging.
| Value, represented as a list of bytes. In a valid Fields, all keys | ||
| and values are valid UTF-8 strings. However, values are not always | ||
| well-formed, so they are represented as a raw list of bytes.</p> | ||
| <p>An error result will be returned if any header or value was | ||
| syntactically invalid, or if a header was forbidden.</p> | ||
| Value, represented as a list of bytes.</p> | ||
| <p>An error result will be returned if any <a href="#field_key"><code>field-key</code></a> or <a href="#field_value"><code>field-value</code></a> is | ||
| syntactically invalid, or if a field is forbidden.</p> |
There was a problem hiding this comment.
I'm confused as to why these doc updates are appearing here; this branch was based on main after #99 landed, which also shows these same diffs 🤔
|
We may not be able to accept this change before 0.3.0 - AFAIK, we are scaling back all of our subtyping aspirations to where just adding new functions to interfaces is permitted, and not changing any of the types defined in those interfaces. |
|
Aha, that makes sense. I'm fine with putting this on ice then or changing the base revision to #101 if that's the best way to start accumulating breaking changes? |
|
I guess in this repo we'll be working on 0.3.0-draft in parallel with 0.2.x-draft, so maybe landing #101 underneath a subdir ( |
|
I like the idea of subdirs with versions as names; this matches what I expect we'll be doing as we release new official minor versions in the main |
|
Thank you for contributing to WASI! As part of our proposal management process, we decided to consolidate all phase 3 proposals into a single monorepo at WebAssembly/wasi to better manage the proposals that have reached phase 3. We have completed migrating all phase 3 proposals to WebAssembly/wasi including their issues, but PRs need to be re-opened in the new repository. This is a GitHub limitation and we're sorry for the inconvenience. Please re-open this PR on WebAssembly/wasi. Thank you! |
4 participants
I failed to notice this was missing in #52. Status codes outside the range of 100-599 are invalid, though there is a nod to implementation-defined behavior outside those valid ranges. In practice we have found it very useful to return error codes specific to status problems to customers since our platform does not support codes outside this range, and the next-best option in the RFC 9209 equivalents is the generic
http-protocol-errorwhich doesn't help a user much with debugging.