feat: make outgoing request based on wasi-http proposal #2520
Conversation
eduardomourar
changed the title
eduardomourar
force-pushed
the
feat/default-wasi-http
branch
4 times, most recently
from
e493194 to
961a98b
Compare
eduardomourar
force-pushed
the
feat/default-wasi-http
branch
from
b4765d8 to
cb812de
Compare
eduardomourar
force-pushed
the
feat/default-wasi-http
branch
3 times, most recently
from
9663bfa to
dea1d6d
Compare
eduardomourar
force-pushed
the
feat/default-wasi-http
branch
2 times, most recently
from
7f99234 to
448091d
Compare
eduardomourar
force-pushed
the
feat/default-wasi-http
branch
2 times, most recently
from
dd12391 to
d830628
Compare
eduardomourar
force-pushed
the
feat/default-wasi-http
branch
from
c6db7b6 to
917e001
Compare
|
|
||
| fn call(&mut self, req: http::Request<SdkBody>) -> Self::Future { | ||
| println!("Adapter: sending request..."); | ||
| let client = DefaultClient::new(None); |
There was a problem hiding this comment.
I assume there isn't much complexity though? You'd just store the DefaultClient on the adapter? In any case, I'm fine with this.
This reverts commit 1ddbd45.
|
I believe all comments have been addressed from this PR. The only thing missing is preparing the |
|
Awesome! We'll give this a final read through this week and get it merged. Thanks for your hard work* on this. |
thanks for the patience as well |
|
what's the status of this? It looks like we meant to merge this but never did for some reason. |
|
Looking into this PR since I need something similar. Looks like it will need slightly more than just fixing up the failing tests. Theres an overview in this Zulip thread but the gist of it is that once the PR for stabilizing the wasi 0.2.0 interfaces is merged we can move the WASI dependencies to point to that. From there we can re-implement some of the type conversions from the previously pulled in |
|
should this PR be closed in favor of #3409? |
Yep, that PR is the continuation of this one but with the finalized WASI 0.2 interfaces |
## Motivation and Context <!--- Why is this change required? What problem does it solve? --> <!--- If it fixes an open issue, please link to the issue here --> This change adds a new crate, `aws-smithy-wasm`, that exports a SDK compatible WASI http client. This is a continuation of the work in #2520 using the now stabilized WASI 0.2.0 interfaces from the [wasi crate](https://crates.io/crates/wasi). This supports, but does not finalize the work for #2087 ## Description <!--- Describe your changes in detail --> Add a new crate, `aws-smithy-wasm` which exports a function `wasi_http_client` that will provide the user with a WASI compatible http client. This client is implemented by using the `wasi::http::outgoing_handler` [ref](https://docs.rs/wasi/0.12.0+wasi-0.2.0/wasi/http/outgoing_handler/index.html) along with some utility implementations of `TryFrom` to transform back and worth between the types from the `http` crate and the `wasi::http` types. It also exports a unit struct `WasmSleep` that impls the `AsyncSleep` trait needed by the SDK. ## Testing <!--- Please describe in detail how you tested your changes --> <!--- Include details of your testing environment, and the tests you ran to --> <!--- see how your change affects other areas of the code, etc. --> This is tested via an integration test in `aws/sdk/integration-tests/webassembly` that uses the wasi http-client to vuild a config and an operation (that is not sent). It is further tested in a new canary (`wasm_canary`) that calls the S3 `list_objects_v2` API. ## Checklist <!--- If a checkbox below is not applicable, then please DELETE it rather than leaving it unchecked --> - [X] I have updated `CHANGELOG.next.toml` if I made changes to the smithy-rs codegen or runtime crates ---- _By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice._ --------- Co-authored-by: Eduardo Rodrigues <[email protected]> Co-authored-by: Eduardo de Moura Rodrigues <[email protected]> Co-authored-by: ysaito1001 <[email protected]> Co-authored-by: John DiSanti <[email protected]> Co-authored-by: Russell Cohen <[email protected]> Co-authored-by: John DiSanti <[email protected]>
Motivation and Context
#2087
This is a continuation of PR #2254, it will replace the mocked HTTP client with one based on the WASI HTTP proposal.
Description
A separate crate called
aws-smithy-wasmwill be created that contains the HTTP connector. This connector can be used during instantiation of the client SDK in order to route HTTP requests through the WebAssembly host.Testing
It has been tested with wasmtime v13. At this moment, the integration test only works with WASI (target
wasm32-wasi, soon to becomewasm32-wasi-preview1). In the context of browsers, an example of usage for a WebAssembly module compiled to WASI can be found here.Checklist
CHANGELOG.next.tomlif I made changes to the smithy-rs codegen or runtime cratesCHANGELOG.next.tomlif I made changes to the AWS SDK, generated SDK code, or SDK runtime cratesBy submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.