-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add http-response-status-invalid
error code
#104
base: main
Are you sure you want to change the base?
Conversation
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
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-error
which doesn't help a user much with debugging.