The problem with gzip bombs in the web context in general is that they operate on the naive assumption that the client will decompress the payload entirely. This is very rarely the case, and you kinda have to go out of your way to make that happen[1], and it really only makes sense if you're looking at some binary format that can't be truncated like you can with HTML.
Instead most if not all clients will use some form of streaming decompression, with a termination criterion, and to the extent stuff is decompressed in full, very rarely will anything be decompressed in full and held in memory, as that would nuke your crawler the first time you ran into a website mirroring linux ISOs.
The problem with gzip bombs in the web context in general is that they operate on the naive assumption that the client will decompress the payload entirely. This is very rarely the case, and you kinda have to go out of your way to make that happen[1], and it really only makes sense if you're looking at some binary format that can't be truncated like you can with HTML.
Instead most if not all clients will use some form of streaming decompression, with a termination criterion, and to the extent stuff is decompressed in full, very rarely will anything be decompressed in full and held in memory, as that would nuke your crawler the first time you ran into a website mirroring linux ISOs.
[1] This is the zlib api for decompressing a gzip file: https://refspecs.linuxbase.org/LSB_3.0.0/LSB-Core-generic/LS...