id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
1896	boost::iostreams::gzip_decompressor silently ignores multiple members	Bruce MacDonald <bruce@…>	Jonathan Turkanis	"The gzip file format RFC 1952 allows for the concatenation of multiple ""members"" in one gzip file.  I have a provider who, unfortunately, sends me gzipped files which consist of about 8 500M (uncompressed) members. Why they are doing this I don't know, but this seems to be a long standing weirdness with gzip.  The gzip command line utility simply decompresses all the members in a single stream and this is the behaviour I would expect from gzip_decompressor.

The gzip_decompressor only processes the first member and silently ignores the others.  In fact, the implementation of read_footer attempts to slurp the rest of the compressed file into a string which it then discards.

In order to read the rest of the members all we have to do is read and process the actual trailer (8 bytes) and then recursively process the rest of the input (perhaps after invoking close() on ourself?).

I have attempted to write a fix for this myself but have been defeated by the complexity of the library."	Bugs	closed	Boost 1.41.0	iostreams	Boost 1.35.0	Problem	fixed	iostreams gzip gzip_decompressor