#47178 [Opn->Sus]: Missing gzip headers in gzencode() output

ID: 47178 Updated by: mike@php.net Reported By: wharmby at uk dot ibm dot com -Status: Open +Status: Suspended Bug Type: Zlib Related Operating System: Windows XP PHP Version: 6CVS-2009-01-21 (snap) Assigned To: mike New Comment: Hi Andy! Sorry for the standard-bla of the quick fix in my previos response. Interestingly, gzencode(..., FORCE_DEFLATE) does not make any sense to me in PHP versions lower than v6. I cannot remember why or even if I noticed this legacy behaviour back when I reimplemented zlib code. For clarification: RFC1951 = raw deflate - not much to say here RFC1950 = zlib encoding, AKA HTTP deflate; - being [zlib header][deflated data][adler checksum] RFC1952 = gzip encoding - being [gzip header][deflated data][crc32 checksum, original size] The output of PHP5s gzencode(..., FORCE_DEFLATE) is neither of the previous formats, but rather zlib encoded data additionally prepended with a gzip header: [gzip header][zlib header][deflated data][adler checksum] This is obscure IMHO. Obviously, this exists and is even documented for ages, so I kindly ask you to take this issue to internals@ for discussion, so people can decide what's going to happen. Thank you. Previous Comments: ------------------------------------------------------------------------ [2009-03-02 11:01:28] wharmby@php.net Hi Mike If you think the bug lies in php5 can you re-assign to that release please. I will fix the PHPT accordingly Regards Andy ------------------------------------------------------------------------ [2009-03-02 10:50:14] wharmby at uk dot ibm dot com Hi Mike Can you expand on your reason for closing this defect as bogus a little more please given that: (1) The same test produces different results on php 5.2 and 5.3, i.e the output from gzencode() with FORCE_DEFLATE includes the zlib headers in both cases. (2) The PHP manual says for the gzencode() option 'encoding mode' "If you use FORCE_DEFLATE, you get a standard zlib deflated string (inclusive zlib headers) after the gzip file header but without the trailing crc32 checksum. " This suggests that the output should include zlib headers. So if the PHP 6 behaviour is correct does this not mean there is a bug in both PHP 5 code and description of the command in the PHP manual ? I raised the bug against PHP 6 as its behaviour differed to previous releases and I assumed it was a bug in the new zlib code but if the bug lies in PHP % I am happy to fix up the new PHPT's and open a defect against PHP 5. Regards Andy Andy Wharmby E-mail: andy_wharmby@uk.ibm.com ------------------------------------------------------------------------ [2009-02-28 14:01:33] mike@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Of course raw deflate encoded data does not have a gzip header. ------------------------------------------------------------------------ [2009-01-21 11:41:35] wharmby at uk dot ibm dot com New tests dropped for gzencode dropped to php 5.2, 5.3 and 6. ext/zlib/tests/gzencode_variation2 ext/zlib/tests/gzencode_variation2-win32 in PHP 6 both tagged with XFAIL sections referencing this defect ------------------------------------------------------------------------ [2009-01-21 10:27:36] wharmby at uk dot ibm dot com Description: ------------ Missing gzip headers in output from gzencode() when FORCE_DEFLATE option specified. Problem persists for all values for $level argument. Problem seen at PHP 6 level only. I will be dropping some new PHPT shortly; the PHP 6 version will be tagged with XFAIL section because of this defect. Reproduce code: --------------- <?php var_dump(bin2hex(gzencode(b"Hello World", -1, FORCE_GZIP))); var_dump(bin2hex(gzencode(b"Hello World", -1, FORCE_DEFLATE))); ?> Expected result: ---------------- Based on output for same script from 5.2/5.3 I expect something like: unicode(62) "1f8b0800000000000003f348cdc9c95708cf2fca49010056b1174a0b000000" unicode(58) "1f8b0800000000000003789cf348cdc9c95708cf2fca490100180b041d" Actual result: -------------- unicode(62) "1f8b080000000000000bf348cdc9c95708cf2fca49010056b1174a0b000000" unicode(38) "789cf348cdc9c95708cf2fca490100180b041d" ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=47178&edit=1