Skip to content

wasi-http: Implement http-error-code, and centralize error conversions #7534

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

Merged
merged 6 commits into from
Nov 14, 2023

Conversation

elliottt
Copy link
Member

Implement the body of http-error-code, and add a test that shows its use when writing too much. This functionality was missing from #7434.

Additionally, add some functions in wasi-http for converting from hyper::Error and http::Error to the new ErrorCode variant. These functions log the error received as a warning, and return the translated error to the guest.

@elliottt elliottt requested a review from a team as a code owner November 14, 2023 01:01
@elliottt elliottt requested review from fitzgen, alexcrichton and pchickey and removed request for a team and fitzgen November 14, 2023 01:01
pub fn http_request_error(err: http::Error) -> bindings::http::types::ErrorCode {
use bindings::http::types::ErrorCode;

tracing::warn!("http request error: {err:?}");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realize that this matches what I was talking about yesterday, where if an error is dropped on the floor it's always at least logged, but I will also say that there's quite a lot of logging going on here. In theory almost all error context should be made available to end users, but it seems like almost all errors are being dropped and canonicalized in bland error codes.

There's not really anything that can be done about that in this PR specifically, but it might be something good to keep in mind for future iterations of wasi-http. One possible example might be something like a "last error as debug string" API or something like that. Or alternatively using wasi:io/error.{error} for all http APIs and then having an optional "pull out the http-specific error kind from each error" API sort of like filesystems. Too late to do this for preview2 but perhaps later.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was going to be a bit noisy, so I've reworked it so that we only log on a path where there's not clear translation back to a wasi-http error (the fall-through cases). Looking more towards the future, I wonder if it would be better to return a wasi:io/error/error instead of a wasi:http/types/error-code. @pchickey and I started working on this last week, but held off on making this change as it was not as easy as swapping out uses of error-code.

@elliottt elliottt force-pushed the trevor/error-code-follow-up branch from 8507bfd to f7c6235 Compare November 14, 2023 18:08
@elliottt elliottt added this pull request to the merge queue Nov 14, 2023
Merged via the queue into bytecodealliance:main with commit 4fe4d3f Nov 14, 2023
@elliottt elliottt deleted the trevor/error-code-follow-up branch November 14, 2023 20:22
@alexcrichton
Copy link
Member

@elliottt is this something that should be backported to Wasmtime 15?

elliottt added a commit to elliottt/wasmtime that referenced this pull request Nov 14, 2023
bytecodealliance#7534)

* Implement the missing http-error-code function

* Add concrete error conversion functions

* Test the error returned when writing too much

* Remove an unused import

* Only log errors when they will get the default representation

* Use `source` instead of `into_cause`
elliottt added a commit that referenced this pull request Nov 15, 2023
* wasi-http: Implement http-error-code, and centralize error conversions (#7534)
* Filter out forbidden headers on incoming request and response resources (#7538)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants