Updates:
Status: WontFix
Comment #3 on issue 20884 by [email protected]: gzip with multiple members
aren't handled properly
http://code.google.com/p/chromium/issues/detail?id=20884
I believe that gzip in the context of content-encoding is only supposed to
handle the
de/compression of a singular stream, to a singular stream. Although gzip
can in
other contexts also be used as an archiver, I don't believe such support
makes sense
for "a" stream. The example cited appears to attempt to use gzip to merge
multiple
streams ("members"), and I think the reference cited is applicable to a
random access
"file" rather than a "stream." The reference above in RFC 1952 shows how
the member
are laid out in an archive file, but it is (for example) not seemingly
asserted that
"decompression of all members" should result in a stream consisting of the
concatenation of those decompressed members in any specific order. I
believe this
bug is asserting that such concatenation during decompression is in the
RFC, but I
didn't see it.
I think the lack of support in IE, FF, etc. supports this view that this is
not a
supported mode of use for gzip (in the context of "content-encoding").
Until someone can cite documentation supporting the concatenation after
decompression
(not the file format showing the members are held sequentially in an
archive), I'm
going to mark this as Won't-Fix (works as intended).
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
--~--~---------~--~----~------------~-------~--~----~
Automated mail from issue updates at http://crbug.com/
Subscription options: http://groups.google.com/group/chromium-bugs
-~----------~----~----~----~------~----~------~--~---
