Repository navigation
Conversation
pchickey
requested review from
alexcrichton and
rvolosatovs
and removed request for
a team
October 6, 2026 23:25
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.
pchickey
force-pushed
the
pch/wasi_http_string_limit
branch
from
October 6, 2026 23:42
f6d2556 to
6724c40
Compare
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR is motivated by string fields in wasip2
outgoing-requestand waspi3requestresources - specifically, thescheme(via theothervariant),method(othervariant),authority, andpath_and_query, being able to use a host allocation of up tohostcall-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.