Repository navigation
Hosts should be able to limit the size of wasi:http/types.fields #889
Description
Currently guests are allowed to create an infinitely sized fields type representing http-headers and infinitely append headers to it. This was a subject of a CVE recently for Wasmtime as this represents a vector of resource exhaustion on the host that can be induced by a guest.
Currently appending a header to fields is allowed to fail, but none of the error reasons cover the situation of "headers are full". Additionally there are no documented limits for what's reasonable for guests to be expected to store in headers. Currently Wasmtime has an arbitrary limit that generates a trap if the guest exceeds it, but this is seen as a temporary band-aid (similar to #888).
Ideally it would be possible for hosts to return a first-class error to the wasm guest indicating "headers are too large" or something like that. Additionally it would be ideal if WASI could document what size of headers hosts are expected to handle on behalf of guests.
Effectively I'd like to make -Smax-http-fields-size=N effectively a noop in Wasmtime by enabling guests to handle any configuration. I'm not sure how best this should work out at the API level in WASI, but at least in my opinion there would ideally be some affordance for "host's aren't forced to buffer infinitely"
Activity
ricochet commentedon Feb 26, 2026
I agree. We should add a first-class error variant to fields mutation operations, e.g.
header-size-exceededonappend,set, andinsert. This lets guests handle the rejection gracefully instead of trapping.We should also include implementer doc comments, like
implementations MUST handle at least 16KB framesso guests have a portable baseline they can rely on (nginx defaults to 8KB per header, Apache to 8KB total, Node.js to 16KB). A 16KB floor matches HTTP/2's minimumSETTINGS_MAX_FRAME_SIZE. So I'm interested in feedback on if setting the floor to 8KB is portable or even desirable.WASI doesn't need the guest to discover the exact limit. The guest just needs to know that
appendmight fail and handle it so I'm not suggesting we exactly follow the http2 reference below by exposing this.Hosts may want to limit individual header values (like Chrome's 4KB Referer cap) or total aggregate size.
References
I went looking for other precedents, so a few links below.
HTTP/2 spec (the closest analogy to this problem):
RFC 9113 (HTTP/2) — the current HTTP/2 spec (obsoletes RFC 7540). Section 6.5.2 defines
SETTINGS_MAX_HEADER_LIST_SIZE, which lets an endpoint advertise the maximum header size it's willing to accept. Exceeding it results in a stream error.RFC 7540 Section 10.5.1 — explicitly says a server receiving a larger header block than it's willing to handle can respond with HTTP 431.
HTTP status code for this exact scenario:
RFC 6585 — defines 431 Request Header Fields Too Large
MDN documentation on 431 — good accessible summary
Chromium-specific:
Chromium source: net/http/http_stream_parser.cc — response header parsing with size enforcement
Chrome limiting Referer header to 4KB — example of Chrome enforcing per-header limits to prevent abuse
feat(http): size-exceeded error variant
feat(http): size-exceeded error variant
feat(http): size-exceeded error variant
feat(http): size-exceeded error variant (WebAssembly#891)