-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
Unexpected Z_BUF_ERROR when using zlib #8701
Comments
@olalonde Okay, first of all, slightly offtopic but still: You’ll probably want to use And then… it’s pretty hard to tell what’s going on or whether this even is a bug in core without a reproducible test case. Could you add |
Thanks for the suggestion. I was reporting this here to be helpful in case there was a bug in core. I'm not the maintainer or owner to that project. I'll try that out though. If you think it's not a bug with zlib feel free to close. |
I don’t know, but I would love to help find that out! :) |
I'll go ahead and close out the issue. Can reopen when new information is available. |
I was having this problem running Node.js v6.9.1 (from NodeSource) on Linux. |
@CTassisF If you can get |
@CTassisF I would also still really recommend trying to give log some/all of the data that is being passed to zlib. |
@bnoordhuis Thanks for your reply! |
I also encountered this issue, and can provide you with a test that can reproduce the issue: While using request to fetch the homepage of a website I got this strange issue on newer node versions, everything is fine on 4.6: $ nvm run --lts=argon reproduceissue.js
Running node LTS "argon" -> v4.6.2 (npm v2.15.11)
working without gzip
working with gzip
$ nvm run --lts=boron reproduceissue.js
Running node LTS "boron" -> v6.9.1 (npm v3.10.8)
not working with gzip
{"errno":-5,"code":"Z_BUF_ERROR"}
working without gzip Here's the code used to reproduce issue: var request = require('request');
request({
url: 'http://www.mantovanispa.it',
gzip: true
}, function(error, response, body)
{
if(!error)
{
console.log('working with gzip');
}
else
{
console.log('not working with gzip');
console.log(JSON.stringify(error));
}
});
request({
url: 'http://www.mantovanispa.it'
}, function(error, response, body)
{
if(!error)
{
console.log('working without gzip');
}
else
{
console.log('not working without gzip');
console.log(JSON.stringify(error));
}
}); The issue seems linked to gzip, maybe this site use a strange way to handle compression, but on older versions of node this won't happen. @bnoordhuis can I help you to debug in some other ways? |
|
Be explicitly lenient with gzip decompression by always requesting `zlib` to flush the input data and never explicitly ending the `zlib` input. The behavioural difference is that on Node ≥ 6, which has a slightly stricter gzip decoding process than previous Node versions, malformed but otherwise acceptable server responses are still properly decompressed (the most common example being a missing checksum at the stream end). This aligns behaviour with cURL, which always uses the `Z_SYNC_FLUSH` flag for decompression. On the downside, accidental truncation of a response is no longer detected on the compression layer. Ref: nodejs/node#8701 (comment)
Be explicitly lenient with gzip decompression by always requesting `zlib` to flush the input data and never explicitly ending the `zlib` input. The behavioural difference is that on Node ≥ 6, which has a slightly stricter gzip decoding process than previous Node versions, malformed but otherwise acceptable server responses are still properly decompressed (the most common example being a missing checksum at the stream end). This aligns behaviour with cURL, which always uses the `Z_SYNC_FLUSH` flag for decompression. On the downside, accidental truncation of a response is no longer detected on the compression layer. Ref: nodejs/node#8701 (comment)
@dege88 fyi, I filed request/request#2492 for the |
Be explicitly lenient with gzip decompression by always requesting `zlib` to flush the input data and never explicitly ending the `zlib` input. The behavioural difference is that on Node ≥ 6, which has a slightly stricter gzip decoding process than previous Node versions, malformed but otherwise acceptable server responses are still properly decompressed (the most common example being a missing checksum at the stream end). This aligns behaviour with cURL, which always uses the `Z_SYNC_FLUSH` flag for decompression. On the downside, accidental truncation of a response is no longer detected on the compression layer. Ref: nodejs/node#8701 (comment) Fixes: request#2482
Ref: nodejs/node#8701 (comment) Ref: request/request#2482 Ref: request/request#2492 Fixes: http://www.mantovanispa.it Fixes: #139
There's been a few
Z_BUF_ERROR
reported on https://github.com/ttezel/twit:ttezel/twit#300
ttezel/twit#269
ttezel/twit#252
ttezel/twit#247
Googling for the error code only brings back to one of those issues or #2043.
It's not clear to me what that error means... The readable stream piping to zlib ended too early? Here's the twit code that creates the zlib stream: https://github.com/ttezel/twit/blob/master/lib/streaming-api-connection.js#L89
The text was updated successfully, but these errors were encountered: