The gzip idea is giving me goosebumps however this must be a solved problem, right? I mean, the client device can also send zip bombs so it sounds like it should be DDOS 101?
At least on the codebases I've worked on, having limits on time and size of any decompression that you do is something that quickly ends up in some internal utility library and nobody would dare directly uncompress anything. Way before you get zip bombs you usually get curious engineers noticing someone uploaded something a bit larger and that increased some average job time by a lot - which then gets fixed before you get big enough to attract zip bombs.
So a zip bomb would just decompress up to whatever internal limit and be discarded.
Yes but the idea behind zip bombs that they appear to be very small, when expanded it can be extremely large. Before attempting to decompress, the POST request may appear something like 20kb and end up being 20gb.
I’d have to assume a decent implementation will eventually give up. It’s almost a given those will not be used by people crawling the internet for quick wins though.
This is a good moment to remind people to always check what are the size limits and timeouts of their servers (and any other relevant limits), no matter if they are libraries or applications. Never assume the defaults are good for you, because sometimes they aren't.
For example, as much as I'd like to praise Go's stdlib because of how far it can take you, the defaults for its HTTP server are "the URL+headers of a request can take as much as 1MB" and "no timeouts at all, wait forever if necessary". See the `Server` type and the `ListenAndServe` function (not method) from the `net/http` package for more details.
They're probably trying to be as conservative as possible, but 1MB is huge.
So a zip bomb would just decompress up to whatever internal limit and be discarded.