gzencode in PHP-5.4 behaves differently than in previous versions.
I outlined the reasoning in the comment from 2009-03-03 22:11 UTC
at http://bugs.php.net/47178
Any comments?
Mike
hi Mike,
gzencode in PHP-5.4 behaves differently than in previous versions.
I outlined the reasoning in the comment from 2009-03-03 22:11 UTC
at http://bugs.php.net/47178Any comments?
As I never used this mode ever (FORCE_DEFLATE), it seems to be used quite often:
http://www.google.com/codesearch#search/&q=gzencode%20lang:php%20FORCE_DEFLATE&type=cs
I wonder how this change actually affects existing code, apps or
tools, in real applications. Obviously the tests were failing due to
the output change but does it affect an application using the data (be
a php or any other app)?
ps: I did not try nor read carefully the specs&docs :)
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Am 28.10.2011 10:59, schrieb Michael Wallner:
gzencode in PHP-5.4 behaves differently than in previous versions.
I outlined the reasoning in the comment from 2009-03-03 22:11 UTC
at http://bugs.php.net/47178
as long gzdecode() can decode stored data from previous versions
without destroy the binary this should not be a big deal
Am 28.10.11 17:29, Reindl Harald schrieb:
Am 28.10.2011 10:59, schrieb Michael Wallner:
gzencode in PHP-5.4 behaves differently than in previous versions.
I outlined the reasoning in the comment from 2009-03-03 22:11 UTC
at http://bugs.php.net/47178
as longgzdecode()can decode stored data from previous versions
without destroy the binary this should not be a big deal
WHAT?
zlib format is not something php made up (more exactly, it's RFC 1950).
There's compatibility with other software implementing the algorithm.
The behavior change probably happened on r299980, when it was rewritten:
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/ext/zlib/zlib.c?r1=298625&r2=299980
The PHP 5.4 behavior seems more correct, as I can inflate it fine, while
on 5.3.8 it fails with
"incorrect header check".
The old behavior seems explained in
http://us.php.net/manual/en/function.gzencode.php#20411
It added a 10-byte gzip header. Given that there's code expecting that
(doing a substr(gzencode(), 10)),
I think it should be readded again, with maybe a new
DEFLATE_NO_GZIP_HEADER option to keep
what is now FORCE_DEFLATE (that could also be done through the new
zlib_encode, depends how it
turns out).