Hilarious because the author, and the OP author, are literally zipping `/dev/null`. While they realize that it "doesn't take disk space nor ram", I feel like the coin didn't drop for them.

Think about it:

  $ dd if=/dev/zero bs=1 count=10M | gzip -9 > 10M.gzip
  $ ls -sh 10M.gzip 
  12K 10M.gzip

Other than that, why serve gzip anyway? I would not set the Content-Length Header and throttle the connection and set the MIME type to something random, hell just octet-stream, and redirect to '/dev/random'.

I don't get the 'zip bomb' concept, all you are doing is compressing zeros. Why not compress '/dev/random'? You'll get a much larger file, and if the bot receives it, it'll have a lot more CPU cycles to churn.

Even the OP article states that after creating the '10GB.gzip' that 'The resulting file is 10MB in this case.'.

Is it because it sounds big?

Here is how you don't waste time with 'zip bombs':

  $ time dd if=/dev/zero bs=1 count=10M | gzip -9 > 10M.gzip
  10485760+0 records in
  10485760+0 records out
  10485760 bytes (10 MB, 10 MiB) copied, 9.46271 s, 1.1 MB/s

  real    0m9.467s
  user    0m2.417s
  sys     0m14.887s
  $ ls -sh 10M.gzip 
  12K 10M.gzip

  $ time dd if=/dev/random bs=1 count=10M | gzip -9 > 10M.gzip
  10485760+0 records in
  10485760+0 records out
  10485760 bytes (10 MB, 10 MiB) copied, 12.5784 s, 834 kB/s

  real    0m12.584s
  user    0m3.190s
  sys     0m18.021s

  $ ls -sh 10M.gzip 
  11M 10M.gzip