Scott Nichol wrote:
FYI, deflate follows Zlib as described in RFC 1950 (http://www.ietf.org/rfc/rfc1950.txt?number=1950). The Zlib DEFLATE method of compression is described in RFC 1951, while gzip is described in RFC 1952 (http://www.ietf.org/rfc/rfc1952.txt?number=1952). RFC 1952 looks like it specifies 10 bytes for the header, so I am not sure why 8 bytes works....
Well, I've been battling with it.
Why 8 bytes works...
zlib already has a 2 byte flag prefix which the gzip compressed data (after its 10 byte header) does not use, so it *looks* like it works appending the 8 bytes.
Here's what I do:
When recieving gzip data:
Remove the first 10 bytes, they are the gzip-specific 10 byte header
Remove the last 8 bytes, they consist of a CRC-32 checksum of the original data, and original data length
Prepend the zlib 2 byte flag: 0x78 0x9c
Call zlib-inflate, and ignore error -5. THis is probably because the buffer ends abruptly with no Adler checksum
When sending data as gzip:
Call zlib-deflate
Remove the 2 zlib flag prefix bytes.
Prepend the 10 byte gzip-specific header
Append a CRC-32 checksum of the original data (Calculated in "DBL" which has no unsigned arithmetic, and no bit-shift operators!)
Append the original data length
This works in that I can compress data, and output it to a file which gunzip will happily inflate to the original data.
I can also see (in my logfile) the correctly inflated SOAP packets coming in to my DBL server.
There does seem to be a problem when SOAP receives by compressed packet. It is throwing "Content is not allowed in prolog."
I still set the Content-Type header to "text/html". Should I change this to indicate to SOAP that it is gzip data coming back?
I'll be back tomorrow, home time now.
Cheers,
Nigel
_____________________________________________________________________ This message has been checked for all known viruses. Virus scanning powered by Messagelabs http://www.messagelabs.com For more information e-mail : [EMAIL PROTECTED]
