Stream: git-wasmtime

Topic: wasmtime / issue #11571 wasmtime serve ignoring scheme in...

Wasmtime GitHub notifications bot (Aug 29 2025 at 18:10):

sepointon opened issue #11571:

Thanks for filing a bug report! Please fill out the TODOs below.

Note: if you want to report a security issue, please read our security policy!

Test Case

https://gitlab.com/sampointon/wasmtime-url-print

Steps to Reproduce

0. Check out the above repository.
1. cargo build --target wasm32-wasip2
2. wasmtime serve target/wasm32-wasip2/debug/wasmtime-url-print.wasm -S cli=y
3. In a new terminal, manually send a HTTP/1.1 request with a scheme that's not http e.g. via netcat - example log (note the request line is in absolute-form):

$ nc localhost 8080
GET https://foo.example/bar HTTP/1.1
Host: baz.example

HTTP/1.1 200 OK
content-type: text/plain
content-length: 22
date: Fri, 29 Aug 2025 17:48:48 GMT

http://foo.example/bar

Expected Results

The https scheme in the request would be preserved.

Actual Results

The scheme was forcibly set to http.

(I do note, happily, that it's doing the right thing and ignoring Host in this instance, so it's not all bad.)

Versions and Environment

Wasmtime version or commit: 36.0.2

Operating system: Fedora 42

Architecture: x86_64

Extra Info

RFC 9112, section 3.3, 'Reconstructing the Target URI`:

The target URI is the request-target when the request-target is in absolute-form. In that case, a server will parse the URI into its generic components for further evaluation.

The current behaviour is entirely explained by line 742 in serve.rs, which is hard-coding the scheme to http.

I see that there's already been some back and forth on this in #8923 and #8878, but the present behaviour is simply wrong according to the spec.

wasmtime should probably defer to the scheme provided by hyper (which I've verified is correct in this case) on the basis that hyper sees the actual request line and can follow the guidance in RFC 9112 section 3.3 depending on whether it's in absolute-form or origin-form. Keeping around a scheme and authority _and_ a request::Parts struct that has its own scheme and authority in HostIncomingRequest seems weird and likely to be a bug magnet.

In practice, most requests in the wild will be origin-form, but I'm getting annoyingly snagged on this because I'm trying to do some local testing of some code that's unhappy if the request URLs aren't as it expects them to be, and I'd like to avoid having to spin up any infrastructure (e.g., DNS, certs, reverse proxies...) for that purpose. This sort of use-case (local testing of wasi-http components in a non-prod environment) seems to be squarely in the domain of wasmtime serve, so it would be useful if it was easy to 'fake' input URLs by using absolute-form requests.

Wasmtime GitHub notifications bot (Aug 29 2025 at 18:10):

sepointon added the bug label to Issue #11571.

Wasmtime GitHub notifications bot (Aug 30 2025 at 16:03):

sepointon commented on issue #11571:

I had a look at making a PR, but I think that there are some decisions to be made first in wasi-http about what exactly is expected of implementations wrt request control data and faithfully reflecting incoming requests vs being convenient (WebAssembly/wasi-http#181).

Wasmtime GitHub notifications bot (Sep 02 2025 at 15:00):

alexcrichton commented on issue #11571:

Thanks for the report! A PR would indeed be quite welcome, and no worries if it requires some spec clarifications first. Thanks for opening the upstream issue!

Wasmtime GitHub notifications bot (Sep 02 2025 at 17:33):

pchickey assigned pchickey to issue #11571.

Last updated: Dec 06 2025 at 06:05 UTC