thats traffic in the other direction

The main joy of a zip bomb is that it doesn't consume much bandwidth - the transferred compressed file is relatively small, and it only becomes huge when the client tries to decompress it in memory afterwards

It's still going in the wrong direction.

It doesn't matter either way. OP was thinking about ways to consume someone's bandwidth. A zip bomb doesn't consume bandwidth, it consumes computing resources of its recipient when they try to unpack it.

i wouldnt assume someone sending 700 req per minute or so to a single domain repeatedly (likely to the same resources) will bother opening zip files.

the bot in the article is likely being tested (as author noted), or its a very bad 'stresser'.

if it was looking for content grabbing it will access differently. (grab resources once and be on its way).

its not bad to host zip bombs tho, for the content grabbers :D nomnom.

saw an article about a guy on here who generated arbitrary pngs or so. also classy haha.

if u have a friendly vps provider who gives unlimited bandwidth these options can be fun. u can make a dashboard which bot has consumed the most junk.

This is using the builtin compression in http:

  Transfer-Encoding: gzip

nearly every http response is gzipped. unpacking automatically is a default feature of every http client.

Accept-Encoding i think would be logical on scrapers these days but maybe its not helpful idk. server should adhere to what client requests afaik.

I know. I was pointing out that it doesn't matter what it consumes if it's going the wrong way to begin with.