Fiddler decompresses a specific GZIP response to a 0-byte body?

[Adam Kim]

I attached an FARX file that shows one autoresponse for

 

https://cm-icmint1vm09.usca.ibm.com:9443/CaseWidgets/catalog/formProxies.json

 

with the original response and the other with the decoded response.

 

The decoded response comes back with a length of 0 when it should contain some content.

 

Is the chunked response bad or is there an issue with Fiddler's decoding mechanism?

[EricLaw]

Tip: Generally speaking, it's much easier to examine traffic in a repro-isolating SAZ file than pulling it from a FARX file.

 

For the file you've sent, the HTTP response in question contains a single chunk which is 94 bytes in length. That 94 byte chunk is compressed with GZIP. First, we use the Transformer tab to remove the HTTP chunked encoding to get to the compressed bytes.

 

According to the browsers, this decompresses to:

 

{
	"localizationProxy": {
		"documentMimeTypes": [
			"application/vnd.icm.ilp"
		]
	}
}

... but Fiddler is decompressing the block to an empty string. Why?

The problem is that the content is malformed. The GZIP format includes an 8 byte "footer" containing a checksum and file size that ensures that the decompressed content matches the original. 

In this case, that footer is corrupt. If I switch out the decompressor with another implementation, it throws the error: {"The calculated checksum differs from the stored checksum."}

I manually parsed the content of the response:

I determined that the problem here is that the server implementation failed to include the file size at the end of the file. As a consequence, it's malformed and cannot be decompressed by a RFC1952-compliant implementation 

(see http://www.ietf.org/rfc/rfc1952.txt).

This seems to be a pretty rare problem with content, since this is perhaps the first report of the issue from the Fiddler community in the last decade. Incidentally, this is a great example of "what not to do" with compression-- the server took an 88 byte file and bloated it up with chunking and compression in order to serve it up as a 105 byte response.