Calling `inflate` on data created from `Pako.deflate` returns `(null, null)`

[brianmhunt]

Some observations that I noted:

inflate fails with (null, null)

inflateSync fails with EOF:

This is probably the most important problem since one would expect either data or an error.

decompress works fine:

deflateSync : incorrect header check

It appears as though Pako has a different idea of what constitutes inflate / deflate i.e.

gzipSync: seems to correspond to pako.inflate

I noted that the builtin CompressionStream seems to correlate with what Pako does i.e. 'inflate' algorithm for Pako and CompressionStream seem to be the same.

zlib: same as gzip

zip: fails, same as deflate

Summary

I've no idea what's going on here (and the issues observed may be with Pako), but I hope the above is useful feedback.

[101arrowz]

All intentional behavior. The names do NOT correspond 1 to 1 with Pako, because Pako named things wrong! It called Zlib "deflate", DEFLATE "deflateRaw", and GZIP "gzip".

fflate.inflate (and fflate.inflateSync) only work on data from pako.deflateRaw. fflate.unzlib (and fflate.unzlibSync) work on data from pako.deflate. fflate.decompress works on anything because it auto-detects header.

pako.inflate is like fflate.decompress: it works on either Zlib or GZIP header, but not raw DEFLATE.

fflate.zipSync is meant to create a ZIP archive, which is a different format entirely from DEFLATE (but ZIP does include DEFLATE internally). You'll need JSZip or zip.js or some other ZIP decompression library to handle data from fflate.zip/fflate.zipSync.

Let me know if there's anything else that confuses you.

[brianmhunt]

Thanks for the prompt reply, and great explanation. I had a feeling it was a pako thing, but I don't have the know-how to make that call.

I think the only thing lingering is whether the (null, null) callback is the correct behaviour. I'd think the API should return either an error or data (or pehaps document when/why (null, null) can happen).

[101arrowz]

I think the only thing lingering is whether the (null, null) callback is the correct behaviour. I'd think the API should return either an error or data (or pehaps document when/why (null, null) can happen).

That's the thing with fflate. It expects you to do everything correctly, the only thing it guarantees is that the browser won't hang when you pass in a bad file. For example, none of the arguments are validated in any of the functions (e.g. for type).

In this case, however, I would expect the first parameter to be non-null. I'll investigate why exactly it's happening; thanks for letting me know.

[101arrowz]

I found and fixed the bug; will be out in v0.7.0.

[101arrowz]

v0.7.0 is released and this bug should be fixed, along with the improved errors from #54.