search

whatwg / compression

Compression Standard
https://compression.spec.whatwg.org/
Other
82 stars 21 forks source link

Introduce "deflate-raw" algorithm #43

Closed yutakahirano closed 2 years ago

yutakahirano commented 2 years ago

This is for https://github.com/WICG/compression/issues/25.

Preview | Diff

yutakahirano commented 2 years ago

@ricea can you take a look?

noell commented 2 years ago

From zlib.net FAQ. 39: What's the difference between the "gzip" and "deflate" HTTP 1.1 encodings?

"gzip" is the gzip format, and "deflate" is the zlib format. They should probably have called the second one "zlib" instead to avoid confusion with the raw deflate compressed data format. While the HTTP 1.1 RFC 2616 correctly points to the zlib specification in RFC 1950 for the "deflate" transfer encoding, there have been reports of servers and browsers that incorrectly produce or expect raw deflate data per the deflate specification in RFC 1951, most notably Microsoft. So even though the "deflate" transfer encoding using the zlib format would be the more efficient approach (and in fact exactly what the zlib format was designed for), using the "gzip" transfer encoding is probably more reliable due to an unfortunate choice of name on the part of the HTTP 1.1 authors.

Source of confusion. Hopefully the new names you choose for the compression API clarifies, compared to the above. Ideal API names would be:

gzip for RFC 1952 zlib for RFC 1950 deflate for RFC 1951 (aka raw)

Note sure if we can use them though, say if the compression API is using already "deflate" to mean "zlib RFC 1950".

ricea commented 2 years ago

Note sure if use them though, if the compression API is using already "deflate" to mean "zlib RFC 1950".

Yes, we chose to align with what HTTP does even though it's not strictly correct. I think the name "deflate-raw" captures the intent quite well.

noell commented 2 years ago

Agree, given the alignment with HTTP constraint, expect "deflate-raw" will work well.