[Catalyst] Fix for content-length issue introduced with Catalyst 5.8.x

[Dominic Germain]

Using Catalyst::Plugin::Unicode::Encoding instead of "hacking" Catalyst.pm =
works, but it brakes some other parts of our code (form posted containing s=
ome accent are screwed up).

Reverting Catalyst.pm to old fashion bytes::length() is way simpler...

Anyone aware of drawback using it instead of length()?

Dominic Germain
---------------------------------------------
Administrateur r=E9seau / Network administrator
Sogetel
www.sogetel.net

mailinglists at sogetel.com



Le 12-02-15 =E0 23:33, Bill Moseley a =E9crit :

> =

> =

> On Thu, Feb 16, 2012 at 10:56 AM, Dominic Germain <mailinglists at sogetel.c=
om> wrote:
> No, we are not using Catalyst::Plugin::Unicode::Encoding
> =

> Does using it fix your problem?   It should.   But, you also should decod=
e input data, too.
> =

> =

> =

> I'm still not sure why that is a separate plugin.  When would you not nee=
d to encode?  Although, seems like should also check for the utf8 flag -- t=
o catch the case where the content has already been encoded.
> =

> =

> -- =

> Bill Moseley
> moseley at hank.org
> _______________________________________________
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.u=
k/
> Dev site: http://dev.catalyst.perl.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20120217/77090=
6cd/attachment.htm