Theodore Brockman (Dec 09 2025 at 19:55): Theodore Brockman (Dec 09 2025 at 19:55):I've started implementing my own handling for compressing and decompressing HTTP response bodies to abstract away those details from component plugin authors (who'll either operate on decoded byte streams or collect all the bytes themselves) -- I was curious whether there are any plans to implement anything like this in wasi-http?
In particular it seems like if I have a series of components which will potentially read/modify the same body that it would be useful for the host to manage any encoding/decoding to prevent duplicated work across invocations (and lead to less code for guests to write) -- though I'm sure there are things I don't yet understand about wasmtime that might make this not the case :sweat_smile:
Joel Dice (Dec 09 2025 at 20:40):One of the first demos I wrote for the component model async feature was request/response (de)compression middleware which can be composed transparently with an arbitrary wasi:http@0.3.0-draft handler component written in any language.
Theodore Brockman (Dec 09 2025 at 20:59):@Joel Dice Yes! I do recall finding this at some point (and it's a very helpful example, thank you!), I suppose I was imagining a host implementation which does so lazily (only at the point body is actually consumed) -- should I take this to mean that the intention is primarily to leave this sort of thing to component composition?
Lann Martin (Dec 09 2025 at 21:05):I believe the middleware example above is "lazy" in that sense. Speaking for myself I think its great when component composition can address functionality like this, and unless you need the absolutely highest possible performance I think its a good place to start.
Joel Dice (Dec 09 2025 at 21:06):If we're talking about e.g. wasmtime serve, then yes, I expect this would be the kind of thing we'd leave to composition. If we're talking about a custom host embedding of Wasmtime, the author of such an embedding is of course free to add as many or as few features as they choose.
In general, adding features like this via composition will be more portable than a a host feature.
And yes, as Lann pointed out, the above middleware is lazy unless I'm misunderstanding what you mean by that term.
Last updated: Jan 09 2026 at 13:15 UTC