Stream: git-wasmtime

Topic: wasmtime / PR #11843 Add `Request::into_http`

view this post on Zulip Wasmtime GitHub notifications bot (Oct 13 2025 at 03:36):

tbrockman opened PR #11843 from ezdevlol:req_into_http to bytecodealliance:main:

Discussion: #wasi > wasi-http Request and pub(crate) Body @ 💬

Largely copies the implementation from Response::into_http as suggested, contains one basic test asserting it works in the happy path.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 13 2025 at 03:36):

tbrockman requested wasmtime-wasi-reviewers for a review on PR #11843.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 13 2025 at 14:32):

dicej submitted PR review:

Thanks for doing this; LGTM.

Please run cargo fmt when you have a chance, which should address the CI failure.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 13 2025 at 14:38):

alexcrichton commented on PR #11843:

Would it also be possible to update the default_send_request to use this new code path as well? I would naively expect the two to be pretty similar in what they're doing.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 13 2025 at 15:48):

tbrockman updated PR #11843.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 13 2025 at 16:05):

tbrockman commented on PR #11843:

Thanks for doing this; LGTM.

Please run cargo fmt when you have a chance, which should address the CI failure.

No problem! Seems a fair exchange for the past/future questions I'll have about wasmtime :grimacing:

Would it also be possible to update the default_send_request to use this new code path as well? I would naively expect the two to be pretty similar in what they're doing.

I looked into this, but I think I might not quite understand the ask as the req parameter already appears to be an http::Request?

view this post on Zulip Wasmtime GitHub notifications bot (Oct 13 2025 at 16:06):

tbrockman edited a comment on PR #11843:

Thanks for doing this; LGTM.

Please run cargo fmt when you have a chance, which should address the CI failure.

No problem! Seems a fair exchange for the past/future questions I'll have about wasmtime :grimacing:

Would it also be possible to update the default_send_request to use this new code path as well? I would naively expect the two to be pretty similar in what they're doing.

I looked into this, but I think I might not quite understand the ask as the req parameter to default_send_request already appears to be an http::Request?

view this post on Zulip Wasmtime GitHub notifications bot (Oct 13 2025 at 16:12):

tbrockman edited a comment on PR #11843:

Thanks for doing this; LGTM.

Please run cargo fmt when you have a chance, which should address the CI failure.

No problem! Seems a fair exchange for the past/future questions I'll have about wasmtime :grimacing:

Would it also be possible to update the default_send_request to use this new code path as well? I would naively expect the two to be pretty similar in what they're doing.

I looked into this, but I think I might not quite understand the ask as the req parameter to default_send_request already appears to be an http::Request?

Edit: Ah, guessing you meant this code which eventually calls default_send_request, which does indeed have some overlap here.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 13 2025 at 16:13):

tbrockman edited a comment on PR #11843:

Thanks for doing this; LGTM.

Please run cargo fmt when you have a chance, which should address the CI failure.

No problem! Seems a fair exchange for the past/future questions I'll have about wasmtime :grimacing:

Would it also be possible to update the default_send_request to use this new code path as well? I would naively expect the two to be pretty similar in what they're doing.

I looked into this, but I think I might not quite understand the ask as the req parameter to default_send_request already appears to be an http::Request?

Edit: Ah, guessing you meant this code which eventually calls default_send_request, which does indeed have some overlap here (if you can confirm that this is what you meant I can dig more into it).

view this post on Zulip Wasmtime GitHub notifications bot (Oct 13 2025 at 16:31):

alexcrichton commented on PR #11843:

Ah yes indeed! That eventually bottoms out here and I think yeah you're right that what you've added here is more suitable for replacing/augmenting the implementation of handle as opposed to default_send_request itself (which is already working at the abstraction level of Hyper types)

view this post on Zulip Wasmtime GitHub notifications bot (Oct 13 2025 at 19:57):

tbrockman commented on PR #11843:

@alexcrichton So I looked into it a bit, and given my limited understanding of handle and how it uses various channels (and perhaps channels, pinning, and tasks in Rust in general), it's not immediately straightforward to me how to integrate Request::into_http in a way that doesn't require adding too much complexity to Request::into_http, without prompting workarounds/redundant code to preserve existing functionality in handle :thinking:

Might need a bit of hand holding here :sweat_smile:

view this post on Zulip Wasmtime GitHub notifications bot (Oct 14 2025 at 15:00):

alexcrichton commented on PR #11843:

Ah ok no worries, I can try to take a look after this merges

view this post on Zulip Wasmtime GitHub notifications bot (Oct 14 2025 at 17:53):

tbrockman commented on PR #11843:

Looks like it leaked some memory during testing as well? :disappointed:

=================================================================
==18584==ERROR: LeakSanitizer: detected memory leaks

Indirect leak of 72 byte(s) in 1 object(s) allocated from:
    #0 0x563417655224  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x14cb224) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #1 0x563417756761  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x15cc761) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #2 0x5634176fc8f9  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x15728f9) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #3 0x5634177a923d  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x161f23d) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #4 0x5634176ae4da  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x15244da) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #5 0x56341771965c  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x158f65c) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #6 0x56341775d61d  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x15d361d) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #7 0x5634176ad96d  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x152396d) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #8 0x5634177a894d  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x161e94d) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #9 0x5634177c1c98  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x1637c98) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #10 0x5634177ffef4  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x1675ef4) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #11 0x5634177d68e3  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x164c8e3) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #12 0x5634177da219  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x1650219) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #13 0x563419c47c6e  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x3abdc6e) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #14 0x563417652b96  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x14c8b96) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)

Indirect leak of 32 byte(s) in 1 object(s) allocated from:
    #0 0x563417655224  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x14cb224) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #1 0x5634176fdb34  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x1573b34) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #2 0x5634177a95f7  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x161f5f7) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #3 0x5634176ae4da  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x15244da) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #4 0x56341771965c  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x158f65c) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #5 0x56341775d61d  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x15d361d) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #6 0x5634176ad96d  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x152396d) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #7 0x5634177a894d  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x161e94d) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #8 0x5634177c1c98  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x1637c98) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #9 0x5634177ffef4  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x1675ef4) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #10 0x5634177d68e3  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x164c8e3) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #11 0x5634177da219  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x1650219) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #12 0x563419c47c6e  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x3abdc6e) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)
    #13 0x563417652b96  (/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521+0x14c8b96) (BuildId: ebb66c38ee1e4fe09240bde1dc91b9090cdf87d4)

SUMMARY: AddressSanitizer: 104 byte(s) leaked in 2 allocation(s).
error: test failed, to rerun pass `-p wasmtime-wasi-http --lib`

Caused by:
  process didn't exit successfully: `/home/runner/work/wasmtime/wasmtime/target/x86_64-unknown-linux-gnu/debug/deps/wasmtime_wasi_http-e2c9f65d23950521` (exit status: 1)
note: test exited abnormally; to see the full output pass --no-capture to the harness.
Error: Process completed with exit code 1.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 14 2025 at 18:23):

rvolosatovs created PR review comment:

This should either error or just panic, see https://github.com/bytecodealliance/wasmtime/blob/ab2486b449d9b8377ffaa2e7a224da390c94a810/crates/wasi-http/src/p3/host/handler.rs#L277-L294

view this post on Zulip Wasmtime GitHub notifications bot (Oct 14 2025 at 18:23):

rvolosatovs submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 14 2025 at 18:29):

rvolosatovs submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 14 2025 at 18:29):

rvolosatovs created PR review comment:

I'm not sure we can actually implement such conversion even without "unwrapping" the body, since e.g. scheme may end up unset, while the wasi-http implementation defaults to ctx.default_scheme(). See also wasi-http docs https://github.com/WebAssembly/wasi-http/blob/14a19b388f4828604a08ede2af8ee1285c020113/wit-0.3.0-draft/types.wit#L278-L284

view this post on Zulip Wasmtime GitHub notifications bot (Oct 14 2025 at 18:29):

rvolosatovs created PR review comment:

We should also test this conversion with scheme unset

view this post on Zulip Wasmtime GitHub notifications bot (Oct 14 2025 at 18:29):

rvolosatovs created PR review comment:

Like I pointed out above, I'd expect the scheme to be set here using the context, like in the handle implementation

view this post on Zulip Wasmtime GitHub notifications bot (Oct 14 2025 at 18:35):

rvolosatovs submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 14 2025 at 18:35):

rvolosatovs created PR review comment:

nit; we've been using this pattern in the p3 implementation so far

                .map_err(|x| match x {})

view this post on Zulip Wasmtime GitHub notifications bot (Oct 14 2025 at 18:39):

rvolosatovs submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 14 2025 at 18:39):

rvolosatovs created PR review comment:

        let http_req = req.into_http(&mut store, async { Ok(()) } ).unwrap();

I don't think passing fut you received from the implementation here is valid, in fact that may be the cause for the memory leak

view this post on Zulip Wasmtime GitHub notifications bot (Oct 14 2025 at 18:40):

rvolosatovs submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 14 2025 at 18:40):

rvolosatovs created PR review comment:

After consuming the body, we should probably also verify that fut resolves to success by polling it once using https://doc.rust-lang.org/std/task/struct.Waker.html#method.noop

view this post on Zulip Wasmtime GitHub notifications bot (Oct 14 2025 at 18:44):

rvolosatovs edited PR review comment.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 14 2025 at 19:54):

alexcrichton commented on PR #11843:

As for the leak, it looks like that's caused by the test added here so I don't think it's spurious. The error message isn't great, however, but if you try running locally it might provide a better error message when llvm-symbolizer is in your $PATH

view this post on Zulip Wasmtime GitHub notifications bot (Oct 14 2025 at 21:06):

tbrockman commented on PR #11843:

Thanks for the detailed review and guidance @rvolosatovs! I'll incorporate the changes when I get a chance.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 16 2025 at 14:51):

tbrockman updated PR #11843.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 16 2025 at 14:53):

tbrockman updated PR #11843.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 16 2025 at 14:55):

tbrockman updated PR #11843.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 17 2025 at 13:32):

rvolosatovs submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 17 2025 at 13:32):

rvolosatovs created PR review comment:

why not use Empty instead? https://docs.rs/http-body-util/latest/http_body_util/struct.Empty.html

view this post on Zulip Wasmtime GitHub notifications bot (Oct 17 2025 at 13:32):

rvolosatovs created PR review comment:

If I understand correctly, into_http fails before it converts the body, which causes this - that makes sense to me, but I think converting the body should be one of the very first things the function should do, which would maybe fix the issue? (see also comments above as to why the order matters)

view this post on Zulip Wasmtime GitHub notifications bot (Oct 17 2025 at 13:32):

rvolosatovs created PR review comment:

If this would error, it would leak memory with no way for the user to fix that.
I still don't think we should implement TryFrom for this conversion

view this post on Zulip Wasmtime GitHub notifications bot (Oct 17 2025 at 13:32):

rvolosatovs created PR review comment:

All of these error cases could leak, since the body handles may not be disposed of correctly, in handle implementation we prevent that by careful ordering of operations - first converting the body (ensuring it will be correctly disposed of on Drop) and then constructing the request https://github.com/bytecodealliance/wasmtime/blob/6b156f234249eb697b6749f369bd36fb5d219d5b/crates/wasi-http/src/p3/host/handler.rs#L219-L299

view this post on Zulip Wasmtime GitHub notifications bot (Oct 17 2025 at 13:35):

rvolosatovs submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 17 2025 at 13:35):

rvolosatovs created PR review comment:

refs https://github.com/bytecodealliance/wasmtime/pull/11440#discussion_r2326139381

view this post on Zulip Wasmtime GitHub notifications bot (Oct 17 2025 at 22:56):

tbrockman submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 17 2025 at 22:56):

tbrockman created PR review comment:

Woops! Think I forgot to remove this (or failed to commit it), it's no longer called, wasn't insisting on keeping it.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 18 2025 at 00:04):

tbrockman submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 18 2025 at 00:04):

tbrockman created PR review comment:

Thanks for the context (and direct link to the PR discussion!), that makes sense, I'll revert the changes in ordering.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 20 2025 at 21:30):

tbrockman submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 20 2025 at 21:30):

tbrockman created PR review comment:

First, some context:

So (apologies if this explanation is unnecessary) this is due to the one section that did mirror what HostWithStore::handle<T> currently does, which returns an error if the content length is invalid first (which is used to determine whether to produce a Limited/UnlimitedGuestBodyConsumer), which is then matched and used to explicitly drop the body:

https://github.com/bytecodealliance/wasmtime/blob/278656ce3be0c0a889fac1d174ba6ffe96dc268e/crates/wasi-http/src/p3/host/handler.rs#L219-L225

This drops the sender side of the channel, which results in the else clause here to be evaluated:

https://github.com/bytecodealliance/wasmtime/blob/278656ce3be0c0a889fac1d174ba6ffe96dc268e/crates/wasi-http/src/p3/request.rs#L75

Then, the question:

Is this how we want things to be handled? A valid content length header is not strictly necessary (so an error could result in setting content_length = None, and the rest of the code could happily proceed), but it does also make sense that creating a Request with an invalid Content-Length header would result in an error, but if so I think I would expect to learn of that error in fut ...that is, if there weren't also this docstring on Request::new:

https://github.com/bytecodealliance/wasmtime/blob/278656ce3be0c0a889fac1d174ba6ffe96dc268e/crates/wasi-http/src/p3/request.rs#L47

view this post on Zulip Wasmtime GitHub notifications bot (Oct 20 2025 at 21:30):

tbrockman edited PR review comment.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 20 2025 at 21:30):

tbrockman edited PR review comment.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 20 2025 at 21:30):

tbrockman edited PR review comment.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 20 2025 at 21:39):

tbrockman edited PR review comment.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 20 2025 at 21:41):

tbrockman updated PR #11843.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 20 2025 at 21:42):

rvolosatovs submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 20 2025 at 21:42):

rvolosatovs created PR review comment:

I don't think this is valid. The Request::new assumes that the host has performed the validation if the request is of foreign origin. For example, if request was received using hyper, it would have to be a valid HTTP request (e.g. with compliant content-length)

This is not a valid content-length header value though, so Request::new should not be called with it

view this post on Zulip Wasmtime GitHub notifications bot (Oct 21 2025 at 03:41):

tbrockman updated PR #11843.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 21 2025 at 03:44):

tbrockman edited PR review comment.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 21 2025 at 03:51):

tbrockman submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 21 2025 at 03:51):

tbrockman created PR review comment:

Ah okay, changed the error scenario to something which should throw on building the URI instead.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 31 2025 at 10:02):

rvolosatovs submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 31 2025 at 10:02):

rvolosatovs created PR review comment:

IIRC GET requests cannot carry a body by the spec

view this post on Zulip Wasmtime GitHub notifications bot (Oct 31 2025 at 15:54):

tbrockman updated PR #11843.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 31 2025 at 15:59):

tbrockman submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 31 2025 at 15:59):

tbrockman created PR review comment:

Changed to POST (though I think per the spec sending a body with GET just doesn't have defined semantics), also rebased and included changes to use boxed_unsync (which were failing tests).

view this post on Zulip Wasmtime GitHub notifications bot (Oct 31 2025 at 15:59):

tbrockman edited PR review comment.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 31 2025 at 16:01):

tbrockman edited PR review comment.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 31 2025 at 16:02):

tbrockman updated PR #11843.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 31 2025 at 16:03):

tbrockman edited PR review comment.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 31 2025 at 16:16):

rvolosatovs submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 31 2025 at 16:17):

rvolosatovs has enabled auto merge for PR #11843.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 31 2025 at 16:43):

rvolosatovs merged PR #11843.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 01 2025 at 18:42):

alexcrichton commented on PR #11843:

Question for y'all: the new method here looks to more-or-less be a copy/paste of this functionality. Would it be possible to unify the two, and if not, how come? The handling of Body::Host for example is quite different between the two and I naively am not entirely sure why.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 03 2025 at 16:22):

rvolosatovs commented on PR #11843:

Question for y'all: the new method here looks to more-or-less be a copy/paste of this functionality. Would it be possible to unify the two, and if not, how come? The handling of Body::Host for example is quite different between the two and I naively am not entirely sure why.

I'm working on a PR, which will align the two

view this post on Zulip Wasmtime GitHub notifications bot (Nov 03 2025 at 17:13):

rvolosatovs commented on PR #11843:

See https://github.com/bytecodealliance/wasmtime/pull/11970

view this post on Zulip Wasmtime GitHub notifications bot (Nov 03 2025 at 17:29):

alexcrichton commented on PR #11843:

Makes sense, thanks!

Last updated: Dec 06 2025 at 06:05 UTC