-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gzip decoder too strict #5761
Comments
@peterkooijmans does this same issue occur on node v5.8.0? |
@evanlucas node v5.8.0 has the exact same behavior. |
Looks like it has been this was since v5. @peterkooijmans could you take a look at #4030 for a potential solution? |
4 tasks
addaleax
added a commit
to addaleax/node
that referenced
this issue
Apr 7, 2016
Up to now, `Z_FINISH` was always the flushing flag that was used for the last chunk of input data. This patch makes this choice configurable so that advanced users can perform e.g. decompression of partial data using `Z_SYNC_FLUSH`, if that suits their needs. Add tests to make sure that an error is thrown upon encountering invalid `flush` or `finishFlush` flags. Fixes: nodejs#5761
MylesBorins
pushed a commit
that referenced
this issue
Apr 20, 2016
Up to now, `Z_FINISH` was always the flushing flag that was used for the last chunk of input data. This patch makes this choice configurable so that advanced users can perform e.g. decompression of partial data using `Z_SYNC_FLUSH`, if that suits their needs. Add tests to make sure that an error is thrown upon encountering invalid `flush` or `finishFlush` flags. Fixes: #5761 PR-URL: #6069 Reviewed-By: James M Snell <[email protected]>
MylesBorins
pushed a commit
that referenced
this issue
Apr 21, 2016
Up to now, `Z_FINISH` was always the flushing flag that was used for the last chunk of input data. This patch makes this choice configurable so that advanced users can perform e.g. decompression of partial data using `Z_SYNC_FLUSH`, if that suits their needs. Add tests to make sure that an error is thrown upon encountering invalid `flush` or `finishFlush` flags. Fixes: #5761 PR-URL: #6069 Reviewed-By: James M Snell <[email protected]>
joelostrowski
pushed a commit
to joelostrowski/node
that referenced
this issue
Apr 25, 2016
Up to now, `Z_FINISH` was always the flushing flag that was used for the last chunk of input data. This patch makes this choice configurable so that advanced users can perform e.g. decompression of partial data using `Z_SYNC_FLUSH`, if that suits their needs. Add tests to make sure that an error is thrown upon encountering invalid `flush` or `finishFlush` flags. Fixes: nodejs#5761 PR-URL: nodejs#6069 Reviewed-By: James M Snell <[email protected]>
jasnell
pushed a commit
that referenced
this issue
Apr 26, 2016
Up to now, `Z_FINISH` was always the flushing flag that was used for the last chunk of input data. This patch makes this choice configurable so that advanced users can perform e.g. decompression of partial data using `Z_SYNC_FLUSH`, if that suits their needs. Add tests to make sure that an error is thrown upon encountering invalid `flush` or `finishFlush` flags. Fixes: #5761 PR-URL: #6069 Reviewed-By: James M Snell <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While talking to a web server on an embedded device, asking for gzip content encoding I get responses that are considered OK by all major browsers (Chrome, Firefox, IE) and also cURL. However, the Node
zlib
module considers the gzip stream incomplete and throws an error. The error returned by thezlib
module reads:Error: unexpected end of file at Zlib._handle.onerror (zlib.js:363:17)
. Inspecting the gzip response it seems to be missing a footer detailing the CRC and the length of the compressed data.A small program that reproduces this with an actual response from the device in it:
Would it be possible to make the Node gzip decoder more lenient and behave more like all major browsers and cURL do?
The text was updated successfully, but these errors were encountered: