Content-Encoding: deflate is actually zlib about fasthttp HOT 8 CLOSED

@sschepens , could you confirm that fasthttp now properly handles Content-Encoding: deflate?

from fasthttp.

As for @klauspost 's compress library, I'll look into it later.

from fasthttp.

AFAIR there are different opinions on what deflate means, which is why Content-Encoding: gzip is generally preferred.

Found a some information from Mark Adler:

[]...
However early Microsoft servers would incorrectly deliver raw deflate for "Deflate" (i.e. just RFC 1951 data without the zlib RFC 1950 wrapper). This caused problems, browsers had to try it both ways, and in the end it was simply more reliable to only use gzip.

The impact in bandwidth and execution time to use gzip instead of "Deflate" (zlib), is relatively small. So there we are and there it is likely to remain.

The difference is 12 more bytes for gzip and slightly more CPU time to calculate a CRC instead of an Adler-32.

CRC will actually be faster on AMD64, since there are assembler optimized routines (if you use my compression package), so the last point isn't valid for Go.

from fasthttp.

@klauspost I know gzip is usually preferred over deflate, but I use some services that only support deflate. I believe nowadays it's more common to have deflate as zlib than raw deflate, and according to standard should be zlib.

from fasthttp.

@klauspost , are there chances for the integration of your compression performance improvements into standard Go library?

from fasthttp.

@valyala - yes, I have just begun submitting the CLs, but it will of course not be out until 1.7.

Meanwhile, it can easily be integrated. There should be nothing more than an import change to use the current code, which is roughly 1.7x faster than the built-in, with no allocations if the Encoder is reused - which you appear to already do.

from fasthttp.

Substituted standard compress library with https://github.com/klauspost/compress

from fasthttp.

👍

from fasthttp.