As gzip compression only applies to the content of the page, not the headers, I would assume that prefixing your page with content that is variably compressible

As gzip compression only applies to the content of the page, not the headers, I would assume that prefixing your page with content that is variably compressible and of varying lengths would throw a monkey wrench in the attacks. The compressed content of any part of a page very much depends on what came before it. Altering the content to include a script comment block full of random text and various common HTML and JavaScript elements (Markov chains anyone?) would definitely change how a page is compressed. If the compressed length of the replies varies significantly with every request - even if the request content is identical - attacks like this can no longer reveal hidden information. Edit: You could improve this significantly by including false positive matches as well. If your HTML content has: csrf="45a7..." in it, you could hash that content into enough material to generate 19 or so identical looking code blocks embedded in a script comment. You've now provided a 95% chance they attack the wrong one / increased the number of attacks they'll need to try by 20x. This method (minus the above part) would actually be cacheable by smart CDNs like Cloudflare.