-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
wasi-http: Fallible fields set and append #7383
wasi-http: Fallible fields set and append #7383
Conversation
36e1f95
to
fe05c4d
Compare
23d2a45
to
4bf5e76
Compare
e9f39e9
to
1df9985
Compare
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.
Looks great overall - rather than trap in the fields constructor, lets make the constructor create an empty set of fields, and have a static function that takes the list<tuple<...>> repr and returns result<fields, header-error>
@pchickey I think (but may be missing a case), that, with the eager-validation changes Trevor made most recently, there isn't a header-related error that can occur in the constructor? Independently, the discussion made me think that perhaps (in a post-Preview-2 timeframe) we should relax the C-M |
The function I agree we should allow constructors to throw in a post-p2 timeframe. |
Ah, gotcha; I was thinking about the case of passing in the already-constructed |
8ce8c72
to
4269e91
Compare
Co-authored-by: Luke Wagner <mail@lukewagner.name>
4269e91
to
66ad714
Compare
This PR makes the
fields.set
andfields.append
methods fallible, and introduces a new error type for describing the ways in which those operations can fail. Additionally it adds a notion of forbidden headers, which will always include the following:There's an embedder-defined hook for adding additional header name validation, but that underlying set of headers can't be altered.
Fixes #7270