I wrote a plug-in for Burp Proxy that decompresses HTTP response content in the ZLIB (RFC1950) and DEFLATE (RFC1951) compression data formats. This arose out of an immediate need on a recent web application security assessment.
Inspecting the HTTP traffic between client and server of the application under review, it appeared that most of the response bodies were compressed and unfortunately not being decoded by Burp (despite the "unpack gzip" option being enabled). The client, a Java applet, relied on response data for a lot of interesting functionality (including access control) and having the ability to easily view and manipulate the contents in plaintext before being received by the applet was clearly beneficial (let's ignore the obvious client-side security issue here ' this is a topic for another discussion).
As I mentioned earlier, it appeared the response content was compressed; however the expected Content-Encoding HTTP response header was not present. Inspection of the de-compiled Java applet code confirmed that compression was being performed with the java.util.zip.Deflater and java.util.zip.Inflater classes. At present, Burp Proxy does not support the ZLIB and DEFLATE compression formats (only GZIP compression is supported).
Burp is an essential tool in any web app testing toolkit and extending its functionality to inflate "deflate" compressed response content via the handy IBurpExtender interface seemed a worthwhile contribution. I hope others find the plug-in useful as well; at a minimum, it will be useful when the application returns for a round of regression testing.
The Burp plug-in can be downloaded here.
Also included with the download is an example servlet called "DeflateTestServlet" for generating HTTP responses bodies in the RFC1950 and RFC1951 compressed formats for testing the plug-in.
Also, here's a good link that may help clarify your understanding of the compression formats used with HTTP.