-
Notifications
You must be signed in to change notification settings - Fork 161
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
"corrupt deflate stream" error #251
Comments
Thanks for the report! I'm not really entirely sure what's going on here, but it could be a bug on either side of things. I don't know much about the library you're using already and how closely it maps to what this crate does. For example I don't know what the I'd recommend trying a few different backends to see if your mileage varies perhaps? |
Thank you, @alexcrichton for your response.
|
Sorry in that case I don't really know what's going on. I think this will require some investigation to see where the binary blobs came from and try to track down where exactly the error is cropping up. |
Any update on this? I'm experiencing the same error on some hard to debug code so I'm fishing for ideas |
At least for the compression side, if I understand the RFC correctly, you need to ensure there is an empty block at the end, and then remove the last 4 bytes (That is , the len and len complement of the empty stored block leaving you with just the block header). You may be able to ensure an empty end block using .flush() (I think that does a sync flush, if not you would have to use the underlying compression functions) before doing .finish. Alternatively according to 7.2.3.4 in the rfc. a 0x00 can be added to the end after .finish() which essentially is adding an empty stored block header to the end manually. It's possible it's failing in both cases due to seeing more data than expected but not sure. |
Not sure if this helps, but I have a similar problem and looked through tons of SO posts and tried various hacks. For a zlib-stream encoded websocket connection, you need a single Inflater object. Then you may start decoding on those. But for my case another issue arises there.
I'm assuming that those wBit restrictions cause issues aswell. I'll fork the lib and play around for a bit. Update: |
Inflate works correctly with pako: const data = Buffer.from([
120, 156, 13, 201, 49, 14, 128, 32, 12, 0, 192, 157, 87, 52, 44, 76, 141, 187,
147, 95, 105, 0, 165, 166, 161, 104, 107, 248, 190, 44, 183, 28, 34, 134, 116,
92, 143, 84, 179, 45, 11, 167, 29, 6, 121, 110, 1, 87, 4, 18, 209, 9, 220,
253, 85, 27, 53, 59, 107, 135, 219, 22, 147, 189, 233, 231, 16, 11, 57, 69,
56, 185, 74, 9, 63, 160,
]);
const pako = require("pako");
const inflator = pako.Inflate();
inflator.push(data, true);
console.log(inflator.err);
console.log(inflator.result);
console.log(inflator.strm.avail_in); But fails with flate2, does anyone know why? CC @alexcrichton |
Background:
I have a C-based client application which talks with server side using Websocket with permessage-deflate extension. "deflate 1.12.11" is the lib used to compress and decompress data.
I want to use Rust to replace this C-based client application.
Expectation:
Sample Data set 1:
Sample Data set 2:
Sample Data set 3:
Sample Data Set 4:
Cargo.toml:
main.rs:
Both decompressions of data set 3 and 4 failed.
'Failed to decompress: corrupt deflate stream'
The text was updated successfully, but these errors were encountered: