Takeshi Yoshino
2017-02-16 09:02:51 UTC
Sending heads up to those who implement or use the permessage-deflate
extension as it might be useful.
zlib (and therefore Chromium and pywebsocket) has been behaving as if
window_bits parameter was set to 9 to compress data even when given the
window_bits parameter set to 8. See
https://github.com/madler/zlib/issues/171 for more details.
Recently, zlib has been updated to return an error when told to use bits 8
by
https://github.com/madler/zlib/commit/049578f0a1849f502834167e233f4c1d52ddcbcc
Chromium hit this error when rolling the new zlib. We decided to explicitly
tell zlib to use window_bits 9 when told to (e.g. by client_max_window_bits
from a server) use 8 to keep the existing behavior. See
http://crbug.com/691074 for more details. For the mean time, we'll just
keep this behavior.
Q: Any visible change made on Chromium's behavior in http://crbug.com/691074
?
A: No
Q: Chromium has not been and is still not honoring client_max_window_bits
correctly?
A: Yes, but effectively no, fortunately ... Because of "Compression Factor
Design Quirk" (see http://www.zlib.net/zlib_tech.html), Chromium has been
using 250 byte back-reference which can be decompressed by an inflater with
256 byte long back reference.
Thanks mark, ricea, yhirano for analysis at http://crbug.com/691074.
extension as it might be useful.
zlib (and therefore Chromium and pywebsocket) has been behaving as if
window_bits parameter was set to 9 to compress data even when given the
window_bits parameter set to 8. See
https://github.com/madler/zlib/issues/171 for more details.
Recently, zlib has been updated to return an error when told to use bits 8
by
https://github.com/madler/zlib/commit/049578f0a1849f502834167e233f4c1d52ddcbcc
Chromium hit this error when rolling the new zlib. We decided to explicitly
tell zlib to use window_bits 9 when told to (e.g. by client_max_window_bits
from a server) use 8 to keep the existing behavior. See
http://crbug.com/691074 for more details. For the mean time, we'll just
keep this behavior.
Q: Any visible change made on Chromium's behavior in http://crbug.com/691074
?
A: No
Q: Chromium has not been and is still not honoring client_max_window_bits
correctly?
A: Yes, but effectively no, fortunately ... Because of "Compression Factor
Design Quirk" (see http://www.zlib.net/zlib_tech.html), Chromium has been
using 250 byte back-reference which can be decompressed by an inflater with
256 byte long back reference.
Thanks mark, ricea, yhirano for analysis at http://crbug.com/691074.