Stream: git-wasmtime

Topic: wasmtime / PR #14598 wasi-http: limit size of strings use...

Wasmtime GitHub notifications bot (Oct 06 2026 at 23:25):

pchickey opened PR #14598 from pchickey:pch/wasi_http_string_limit to bytecodealliance:main.

Wasmtime GitHub notifications bot (Oct 06 2026 at 23:25):

pchickey requested rvolosatovs for a review on PR #14598.

Wasmtime GitHub notifications bot (Oct 06 2026 at 23:25):

pchickey requested wasmtime-wasi-reviewers for a review on PR #14598.

Wasmtime GitHub notifications bot (Oct 06 2026 at 23:25):

pchickey requested alexcrichton for a review on PR #14598.

Wasmtime GitHub notifications bot (Oct 06 2026 at 23:25):

pchickey requested wasmtime-core-reviewers for a review on PR #14598.

Wasmtime GitHub notifications bot (Oct 06 2026 at 23:33):

pchickey edited PR #14598:

This PR is motivated by string fields in wasip2 outgoing-request and waspi3 request resources - specifically, the scheme (via the other variant), method (other variant), authority, and path_and_query, being able to use a host allocation of up to hostcall-fuel (128M by default) size strings.

This PR limits the sum those by default to 16k per request, which I picked a reasonable limit given that many http implementations limit the sum of all of these strings plus the headers anywhere from 8k (akamai), 32k (nginx), to 128k (fastly, cloudflare). The limit is tunable in the construction of WasiHttpCtx, the C API, and the wasmtime cli (with -Smax-http-request-strings-size=).

Also, this PR noticed that the http fields size limit wasn't settable in the C API, so that setting was added as well.

Wasmtime GitHub notifications bot (Oct 06 2026 at 23:38):

pchickey edited PR #14598:

This PR is motivated by string fields in wasip2 outgoing-request and waspi3 request resources - specifically, the scheme (via the other variant), method (other variant), authority, and path_and_query, being able to use a host allocation of up to hostcall-fuel (128M by default) size strings.

This PR limits the sum those by default to 16k per request, which I picked a reasonable limit given that many http implementations limit the sum of all of these strings plus the headers anywhere from 8k (akamai), 32k (nginx), to 128k (fastly, cloudflare). The limit is tunable in the construction of WasiHttpCtx, the C API, and the wasmtime cli (with -Smax-http-request-strings-size=).

The limits apply to all requests that come off the wire, as well as those manipulated by the guest, so that we keep the invariant that the guest can proxy (forward) any request it is given. Requests that come off the wire exceeding the limit get rejected with 400 BAD_REQUEST. Along the way, the validation of the host header was made stricter when the request doesn't already have an authority - it now must parse as an http::uri::Authority. These changes may end up causing embeddings to reject some requests they previously accepted, but they should be able to tweak the limit to continue accepting any valid requests.

New tests demonstrate this new limit on wasip2 and wasip3. There are some incidental changes to the crate's public api for wasip3, and wasip2's HostOutgoingRequest can no longer be constructed outside the crate through the struct fields, but that one didn't strike me as an intentional aspect of the public API. If there are embedder depending on that, we can make all of the new machinery validation machinery pub, but I chose to keep it as an internal implementation detail.

Also, this PR noticed that the http fields size limit wasn't settable in the C API, so that setting was added as well.

Wasmtime GitHub notifications bot (Oct 06 2026 at 23:42):

pchickey updated PR #14598.

Wasmtime GitHub notifications bot (Oct 07 2026 at 01:20):

github-actions[bot] added the label wasmtime:c-api on PR #14598.

Wasmtime GitHub notifications bot (Oct 14 2026 at 13:45):

:memo: rvolosatovs submitted PR review.

Wasmtime GitHub notifications bot (Oct 14 2026 at 13:45):

:speech_balloon: rvolosatovs created PR review comment:

this would surface as trap and abort all requests currently being processed by the worker (e.g. in p3 a single worker is processing multiple requests concurrently using the same instance). This means that a single bad request originating from the client could abort handling of all requests that were accepted and currently being processed by the worker using the instance.

See L525 and L593

Wasmtime GitHub notifications bot (Oct 14 2026 at 13:45):

:speech_balloon: rvolosatovs created PR review comment:

Is this the right place for this check? Currently, Request::new and from_http perform no validation, the assumption is that requests originating from the host have been validated beforehand, in other words passing an invalid request here is an embedder's error.

For example, as documented, these functions do not validate content-length.

I'd argue that this function should be infallible as before and validation should be performed before conversion.

This would keep consistency with content-length handling and we could fail early returning a clear error without tearing down the worker.

Wasmtime GitHub notifications bot (Oct 14 2026 at 13:45):

:speech_balloon: rvolosatovs created PR review comment:

this should probably use crate::parse_authority

Wasmtime GitHub notifications bot (Oct 15 2026 at 14:42):

alexcrichton unassigned alexcrichton from PR #14598 wasi-http: limit size of strings used to describe Request's non-headers,body parts.

Wasmtime GitHub notifications bot (Oct 27 2026 at 20:00):

pchickey converted PR #14598 wasi-http: limit size of strings used to describe Request's non-headers,body parts to a draft.

Wasmtime GitHub notifications bot (Oct 27 2026 at 20:00):

pchickey commented on PR #14598:

This needs significant reworking and isn't currently a priority. I might get back to this in the future

Last updated: Oct 31 2026 at 23:03 UTC