Bug #75237 for Catalyst-Plugin-Unicode-Encoding: Problem with using Catalyst::Plugin::Unicode::Encoding and Catalyst::Plugin::Compress together

Thu Feb 23 05:02:06 2012 thijs.oppermann [...] tty.nl - Ticket created

Subject:	Problem with using Catalyst::Plugin::Unicode::Encoding and Catalyst::Plugin::Compress together
Date:	Thu, 23 Feb 2012 11:01:49 +0100
To:	bug-Catalyst-Plugin-Compress [...] rt.cpan.org, bug-Catalyst-Plugin-Unicode-Encoding [...] rt.cpan.org
From:	Thijs Oppermann <thijs.oppermann [...] tty.nl>

First of all, Catalyst::Plugin::Compress tells me how I should use it with Catalyst::Plugin::Unicode, but Catalyst::Plugin::Unicode tells me it's deprecated in favor of Catalyst::Plugin::Unicode::Encoding. So maybe this link in the POD can be corrected to point to Catalyst::Plugin::Unicode::Encoding. However, using these two together (Catalyst::Plugin::Unicode::Encoding and Catalyst::Plugin::Compress) doesn't work. I get a 'Content Encoding Error' in my browser and a 'Wide character in memGzip' exception in my apache log. Changing the order in with I 'use' them doesn't help. I think the problem is that Catalyst::Plugin::Compress hooks into 'finalize', while Catalyst::Plugin::Unicode::Encoding hooks into 'finalize_headers'. This means that Catalyst::Plugin::Unicode::Encoding will always run *after* Catalyst::Plugin::Compress (I think?), which is of course exactly what you *don't* want. I've written my own Compress plugin that hooks into 'finalize_headers' and that does work. I'm not sure that that's the correct place, though, so maybe the solution should be to hook Catalyst::Plugin::Unicode::Encoding into 'finalize' instead. Thijs

Fri Aug 03 07:16:43 2012 mark [...] blackmans.org - Correspondence added

From:

mark [...] blackmans.org

I can confirm this and that the best fix is to overload finalize instead of finalize_headers and it's enough to simply change the name of the sub in Catalyst::Plugin::Unicode::Encoding.pm --- /Users/mark/.perlbrew/libs/perl- 5.10.1@fairfx/lib/perl5/Catalyst/Plugin/Unicode/Encoding.pm 2012-08-03 11:55:13.000000000 +0100 +++ FX/lib/Catalyst/Plugin/Unicode/Encoding.pm 2012-08-03 12:12:50.000000000 +0100 @@ -35,7 +35,7 @@ return $encoding; } -sub finalize_headers { +sub finalize { my $c = shift; my $body = $c->response->body; On Thu Feb 23 05:02:06 2012, thijs.oppermann@tty.nl wrote: Show quoted text

> First of all, Catalyst::Plugin::Compress tells me how I should use it > with Catalyst::Plugin::Unicode, but Catalyst::Plugin::Unicode tells me > it's deprecated in favor of Catalyst::Plugin::Unicode::Encoding. > > So maybe this link in the POD can be corrected to point to > Catalyst::Plugin::Unicode::Encoding. > > However, using these two together (Catalyst::Plugin::Unicode::Encoding > and Catalyst::Plugin::Compress) doesn't work. I get a 'Content Encoding > Error' in my browser and a 'Wide character in memGzip' exception in my > apache log. > > Changing the order in with I 'use' them doesn't help. > > I think the problem is that Catalyst::Plugin::Compress hooks into > 'finalize', while Catalyst::Plugin::Unicode::Encoding hooks into > 'finalize_headers'. This means that Catalyst::Plugin::Unicode::Encoding > will always run *after* Catalyst::Plugin::Compress (I think?), which is > of course exactly what you *don't* want. > > I've written my own Compress plugin that hooks into 'finalize_headers' > and that does work. I'm not sure that that's the correct place, though, > so maybe the solution should be to hook > Catalyst::Plugin::Unicode::Encoding into 'finalize' instead. > > Thijs >

Fri Aug 03 07:16:46 2012 The RT System itself - Status changed from 'new' to 'open'