Ethereal-dev: RE: [Ethereal-dev] HTTP gzip/deflate decompression patch - zlib a nd gzip on Win
I fear that zlib1.dll doesn't provide in-memory expansion of a *gzip*
encoded *memory buffer* (only file decompression), if I may believe what's
written in the zlib.h header file :(
Quoting from zlib.h:
#define ZLIB_VERSION "1.2.1"
#define ZLIB_VERNUM 0x1210
/*
The 'zlib' compression library provides in-memory compression and
decompression functions, including integrity checks of the uncompressed
data. This version of the library supports only one compression method
(deflation) but other algorithms will be added later and will have the
same
stream interface.
Compression can be done in a single step if the buffers are large
enough (for example if an input file is mmap'ed), or can be done by
repeated calls of the compression function. In the latter case, the
application must provide more input and/or consume the output
(providing more output space) before each call.
The compressed data format used by the in-memory functions is the zlib
format, which is a zlib wrapper documented in RFC 1950, wrapped around a
deflate stream, which is itself documented in RFC 1951.
The library also supports reading and writing files in gzip (.gz)
format
with an interface similar to that of stdio using the functions that start
with "gz". The gzip format is different from the zlib format. gzip is a
gzip wrapper, documented in RFC 1952, wrapped around a deflate stream.
The zlib format was designed to be compact and fast for use in memory
and on communications channels. The gzip format was designed for single-
file compression on file systems, has a larger header than zlib to
maintain
directory information, and uses a different, slower check method than
zlib.
This library does not provide any functions to write gzip files in
memory.
However such functions could be easily written using zlib's deflate
function,
the documentation in the gzip RFC, and the examples in gzio.c.
The library does not install any signal handler. The decoder checks
the consistency of the compressed data, so the library should never
crash even in case of corrupted input.
*/
Regards,
Olivier
|-----Original Message-----
|From: Jerry Talkington
|
|On Thu, May 06, 2004 at 03:46:07PM +0200, Biot Olivier wrote:
|
|> |From: Jerry Talkington
|> |
|> |Hmm, it seems to decode fine on my Mac. I've got to
|> |recompile on linux
|> |before I can check it out there, since there seems to be a
|> |problem with
|> |gtk-2.0 when compiling from cvs. I won't be able to check
|> |it out until tonight.
|> |
|> |What platform are you having the problem uncompressing on, and which
|> |version of zlib do you have? I may need to add some more tweaks for
|> |that particular version...
|>
|> I have tested this with a MSVC++ build with GTK2 from a
|> fresh CVS snapshot.
|> It uses libz 1.2.1 (zlib1.dll version 1.2.1.0). I'll give my
|> cygwin build a
|> try at home tonight too (that takes about 1 hour to compile though).
|
|I haven't tried doing a windows build yet, but I'll give it a shot when
|I get home tonight.
|
|> Maybe the zlib1.dll code requires special care. This should
|> be visible from
|> the file open stuff in ethereal as we're able to read
|> compressed captures on either MS Win as on *NIX.
|
|Opening files uses gzRead() and the like, but reading from streams uses
|inflate(), which is what seems to be the problem. It's very particular
|about the input that it will accept, which is why I had to add three
|passes into tvb_uncompress(). There is probably a fourth that needs to
|be added ;)
Regards,
Olivier
