Most servers will limit posts to a fairly low size by default.

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.

> I’d have to assume a decent implementation will ...

Just like all good c code always checks for overflows.

You close the socket as soon as you see "POST" and there's no POST handler registered.

what if you accept post for legit reasons?

Then you should use an HTTP library that lets you limit the uncompressed body size, and terminate the socket as soon as the limit is reached.

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.