GZIP not really gzip

General JUCE discussion
1

Hey Jules, I’ve recently been using GZIPCompressorHelper to send back response text to http clients. If the client is using ‘deflate’ as the Accept-Encoding, I can use the library as is… The iphone however just supports gzip and if I send it back labelled as such (Content-Encoding: gzip), it works, but safari/chrome complain with error 300 (Content can’t be decoded).

Turns out I can make a gzip compatible stream by modding GZIPCompressorHelper and changing the windowbits from MAX_WBITS(which is defined as 15 in 10.4u SDK) to 15+16. I’m wondering if you can add a parameter to the GZIPCompressorOutputStream to enforce gzip headers?

Below is the appropriate info from zlib docs

[quote] windowBits can also be greater than 15 for optional gzip encoding. Add 16 to windowBits to write a simple gzip header and trailer around the compressed data instead of a zlib wrapper. The gzip header will have no file name, no extra data, no comment, no modification time (set to zero), no header crc, and the operating system will be set to 255 (unknown). If a gzip stream is being written, strm->adler is a crc32 instead of an adler32.
[/quote]

Tnx!

2

There’s already a ‘nowrap’ parameter that is used to change the window size for zip files… Perhaps I should just replace the nowrap parameter by a number of bits that could be passed straight through to zlib? Would that do the trick for what you’re trying to do?

3

That’d be awesome, tnx!