lukechilds/node - node - Gitea: Git with a cup of tea

16005 Commits

131 Branches

446 Tags

325 MiB

Tree: 0aab0503be

Commit Graph

Author	SHA1	Message	Date
Michael Lefkowitz	86e39367d6	test: improve zlib-from-gzip-with-trailing-garbage * use assert.strictEqual instead of assert.equal * add RegExp in second argument of assert.throws * validate error message and code PR-URL: https://github.com/nodejs/node/pull/10674 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>	8 years ago
Anna Henningsen	54a5287e3e	zlib: fix gzip member head/buffer boundary issue Make sure that, even if an `inflate()` call only sees the first few bytes of a following gzip member, all members are decompressed and part of the full output. This change also modifies behaviour for trailing garbage: If there is trailing garbage which happens to start with the gzip magic bytes, it is no longer discarded but rather throws an error, since we cannot reliably tell random garbage from a valid gzip member anyway and have to try and decompress it. (Null byte padding is not affected, since it has been pointed out at various occasions that such padding is normal and discarded by `gzip(1)`, too.) Adds tests for the special case that the first `inflate()` call receives only the first few bytes of a second gzip member but not the whole header (or even just the magic bytes). PR-URL: https://github.com/nodejs/node/pull/5883 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: James M Snell <jasnell@gmail.com>	9 years ago
Kári Tristan Helgason	f380db237b	zlib: add support for concatenated members According to the spec gzipped archives can contain more than one compressed member. Previously Node's gzip implementation would only unzip the first member and throw away the rest of the compressed data. Issue #4306 is an example of this occurring in daily use. Fixes: https://github.com/nodejs/node/issues/4306 PR-URL: https://github.com/nodejs/node/pull/5120 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: James M Snell <jasnell@gmail.com>	9 years ago

Author

SHA1

Message

Date

Michael Lefkowitz

86e39367d6

test: improve zlib-from-gzip-with-trailing-garbage

* use assert.strictEqual instead of assert.equal
* add RegExp in second argument of assert.throws
* validate error message and code

PR-URL: https://github.com/nodejs/node/pull/10674
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>

8 years ago

Anna Henningsen

54a5287e3e

zlib: fix gzip member head/buffer boundary issue

Make sure that, even if an `inflate()` call only sees the first
few bytes of a following gzip member, all members are decompressed
and part of the full output.

This change also modifies behaviour for trailing garbage:
If there is trailing garbage which happens to start with the
gzip magic bytes, it is no longer discarded but rather throws
an error, since we cannot reliably tell random garbage from
a valid gzip member anyway and have to try and decompress it.
(Null byte padding is not affected, since it has been pointed
out at various occasions that such padding is normal and
discarded by `gzip(1)`, too.)

Adds tests for the special case that the first `inflate()` call
receives only the first few bytes of a second gzip member but
not the whole header (or even just the magic bytes).

PR-URL: https://github.com/nodejs/node/pull/5883
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>

9 years ago

Kári Tristan Helgason

f380db237b

zlib: add support for concatenated members

According to the spec gzipped archives can contain more than one
compressed member. Previously Node's gzip implementation would only
unzip the first member and throw away the rest of the compressed data.
Issue #4306 is an example of this occurring in daily use.

Fixes: https://github.com/nodejs/node/issues/4306
PR-URL: https://github.com/nodejs/node/pull/5120
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>

9 years ago

3 Commits (0aab0503be1f3108778005cad48a91a95082e187)