I've been trying to imagine if there's any good reason for doing this - it's relatively simple to detect which browser is making the request and thus make a compressed response hence it doesn't provide much protection against zip-bombs.

It occurred to me that these appliances may expect to provide zip-bomb protection by rejecting compressed content and are simply advertising the fact - however this approach won't work if the zip bomb is implemented as a (e.g.) a GIF file.
–
symcbeanAug 10 '12 at 10:46

1 Answer
1

One explanation: Compressed data is harder to parse in real-time. If the product is performing some sort of content filtering on the live HTTP streams it is easier to deal with non-compressed streams. It may be scanning for malware, or blocking unapproved content (some of those products are enterprise oriented).

If the firewall is trying to parse the stream, it is advantageous to not have to deal with compressed streams. That requires buffering and decompressing the data after enough of it has been assembled, as well as a little CPU overhead in having to decode the compressed stream a total of twice. (Also, it's simply more effort.)

But IME using compression on HTTP is a win-win - yes it takes CPU cycles to compress the data - but fewer cycles than it takes to squirt the un-compressed data across the network. It also takes less time, hence compress/send/decompress/scan should be faster and require less processing than send/scan :(
–
symcbeanAug 10 '12 at 10:44

Compression may be advantageous for the server, but the firewall is doing this on the client and it probably isn't concerned with what is most convenient for the server, or even what's fastest for the overall end-to-end network.
–
B-ConAug 10 '12 at 21:35