Error: http: request body too large (recovered by wazero)

[mtb0x1]

Command to reproduce :

cli --allow-host "cdimage.debian.org" call wasm/http.wasm http_request --input '{"url": "https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-12.4.0-amd64-netinst.iso"}' > debian.iso

Result :

Error: http: request body too large (recovered by wazero)
wasm stack trace:
        extism:host/env.http_request(i64,i64) i64
        ._ZN10extism_pdk4http7request17h4b0709172c155b02E(i32,i32,i32,i32)
        .http_request() i32

Expected Result :

iso file downloaded entirely, if not a warning/error message explaining the reason.

in runtime/src/pdk.rs, there is a limit set to 50MB (?).

extism/runtime/src/pdk.rs

Lines 240 to 242 in 1a083f6

	reader
	.take(1024 * 1024 * 50) // TODO: make this limit configurable
	.read_to_end(&mut buf)?;

My question I guess is, beyond the TODO to configure the limit, is there a hard-limit that we should worry about either due to Extism or WASI design.

[zshipko]

I just opened a PR to update the CLI to add the --http-response-max: extism/cli#64 after adding the new manifest field: #674

Other than that the only other limit I can think of is the 32-bit address space. Also, this setting only applies to calls to extism_http_request, it doesn't have any affect on any WASI configuration.

[mtb0x1]

Now I get a random signal : killed, monitoring the execution using 'top' the memory goes up to ~5gb. (my vm has 6gb max)

Steps :

1. Clone extism/extism,extism/cli,extism/rust-pdk,extism/plugins into /tmp
2. Change /tmp/plugins/Cargo.toml to use /tmp/rust-pdk instead of git version.
3. Change /tmp/rust-pdk/Cargo.toml to use /tmp/extism/manifest and /tmp/extism/convert instead of public version.
   (the /tmp/extism is the last version from git)
4. Update /tmp/cli with PR 'http-response-max' gh pr checkout 64
5. Build plugins cd /tmp/plugins && cargo build
6. Run go run /tmp/cli/extism/main.go --allow-host "cdimage.debian.org" --http-response-max 1048576000 call /tmp/plugins/target/wasm32-unknown-unknown/debug/http.wasm http_get --input '{"url": "https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-12.4.0-amd64-netinst.iso"}' > debian.iso
   (1048576000 ~= 1gb)

from what I gathered --http-response-max xyz works fine, when I specify 524288000 (~=500Mb) as a value I get the usual request body too large. (the iso size is ~700Mb)

I ran a quick check and I might be missing things, my guess the excessive memory usage happens in

extism/runtime/src/current_plugin.rs

Line 103 in fc22412

pub fn memory_new<'a, T: ToBytes<'a>>(&mut self, t: T) -> Result<MemoryHandle, Error> {

// +1gb allocated in `http_request`, then in 
    pub fn memory_new<'a, T: ToBytes<'a>>(&mut self, t: T) -> Result<MemoryHandle, Error> {
        let data = t.to_bytes()?; //<= +700mb ?
        let data = data.as_ref();
        if data.is_empty() {
            return Ok(MemoryHandle::null());
        }
        let handle = self.memory_alloc(data.len() as u64)?; //<= +700mb ?
        let bytes = self.memory_bytes_mut(handle)?;
        bytes.copy_from_slice(data.as_ref()); //<= +700mb ?
        Ok(handle)
    }
   //=> ~4gb and I am probably missing out some other allocations.

I didn't have time to run Valgrind to confirm, in any case, this is not urgent but I think it's worth following up as there is room for improvement that would benefit the memory management and speed of extism runtime.

[zshipko]

Thanks for testing it out! Your example does download the full ISO on my machine, but memory use seemed to peak at ~4GB, so there is definitely some room to improve memory use around large HTTP responses. I will investigate a little further today.

[nilslice]

@mtb0x1 we merged a solution for this last week, just want to follow up to make sure you saw & see if it works for you!

[mtb0x1]

I tested with the change in http plugin, memory usage did improve and peak usage did go down from +4Gb to 2.7Gb.
(This is not a real use-case on my side and I am not sure if you need to spend more time on it)
You can close it :)