Skip Menu |

This queue is for tickets about the CGI-Compress-Gzip CPAN distribution.

Report information
The Basics
Id: 32124
Status: rejected
Priority: 0/
Queue: CGI-Compress-Gzip

People
Owner: Nobody in particular
Requestors: dietrich.streifert [...] googlemail.com
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 0.22
Fixed in: (no value)



Subject: Changes to CGI::Util method escape breaks compatibility to CGI::Compress::Gzip
We are using CGI and CGI::Compress::Gzip to automatically compress output of html (Indirectly by using CGI::Application and CGI::Application::Plugin::CompressGzip). After updating from CGI V 3.29 to V 3.33 the output seemed to be created as UTF-8 independent from the charset settings in the file or header. This was for pages adding cookies to the header. After examining the code it turned out that changes in the method escape in CGI::Util from $toencode = eval { pack("C*", unpack("U0C*", $toencode))} || pack("C*", unpack("C*", $toencode)); to (change from "C*" to "U*" in the first pack call) $toencode = eval { pack("U*", unpack("U0C*", $toencode))} || pack("C*", unpack("C*", $toencode)); Caused the problem. I don't know if this problem can be solved in this module because CGI.pm caused the problem. I've report this also to the CGI module RT. Thank you for your help and your great module. Happy new year.
From: dietrich.streifert [...] googlemail.com
Any news on this subject? Regards.
From: dietrich.streifert [...] googlemail.com
This was a CGI module issue. See http://rt.cpan.org/Public/Bug/Display.html?id=32122 This bug should be closed.
As per the previous comment, it appears that this was not the fault of CGI::Compress::Gzip. Rejecting.