"Compression bombs that use the zip format must cope with the fact that DEFLATE, the compression algorithm most commonly supported by zip parsers, cannot achieve a compression ratio greater than 1032. For this reason, zip bombs typically rely on recursive decompression, nesting zip files within zip files to get an extra factor of 1032 with each layer. But the trick only works on implementations that unzip recursively, and most do not."

https://www.bamsoftware.com/hacks/zipbomb/

2000 bytes limit

Which is enough to store any content (unzipped it just needs to contain a link to the next chunk)

Plenty of room for a recursive function with no base case

You're not getting very far on 2k bytes. A 10k file expands to 10MB and will likely timeout if the author's webhost configured proper limits

Files are not decompressed in the server: it sends the unmodified deflate stream back to the user.

See my comment about this upstream, here: https://news.ycombinator.com/item?id=37410473

Wouldn't infinitely spawning web workers do the same thing as a zip bomb?

```

<script>

   const workerBlob = new Blob(['

        while (true) { console.log("this is a worker that will never stop") }

    '], { type: 'application/javascript' })

   const workerBlobURL = URL.createObjectURL(workerBlob)

   while (true) { new Worker(workerBlobURL) }

</script>

```

The zip file is decompressed on the server, whereas that HTML/JS will be executed on the client

I see, I misunderstood