I would think Transfer-Encoding would be a better choice than Content-Encoding. It's processed at a lower level of the stack and <i>must</i> be decoded – Content-Encoding is generally only decoded if the client is specifically interested in whatever's inside the payload. (Note that you don't have to specify the large Content-Length in this case as it is implied by the transfer coding.)<p>Also worth trying is an XML bomb [1], though that's higher up the stack.<p>Of course you can combine all three in one payload (since it's more likely that lower levels of the stack implement streaming processing): gzip an XML bomb followed by a gigabyte of space characters, then gzip that followed by a gigabyte of NULs, then serve it up as application/xml with both Content-Encoding and Transfer-Encoding: gzip.<p>(Actually now that I think of it, even though a terabyte of NULs compresses to 1 GiB [2], I bet <i>that</i> file is itself highly compressible, or could be made to be if it's handcrafted. You could probably serve that up easily with a few MiB file using the above technique.)<p>EDIT: In fact a 100 GiB version of such a payload compresses down do ~160 KiB on the wire. (No, I won't be sharing it as I'm pretty sure that such reverse-hacking is legally not much different than serving up malware, especially since black-hat crawlers are more likely than not running on compromised devices.)<p>[1] <a href="https://en.wikipedia.org/wiki/Billion_laughs" rel="nofollow">https://en.wikipedia.org/wiki/Billion_laughs</a><p>[2] <a href="https://superuser.com/questions/139253/what-is-the-maximum-compression-ratio-of-gzip/579290" rel="nofollow">https://superuser.com/questions/139253/what-is-the-maximum-c...</a>