[Catalyst] Re: Avoiding UTF8 in Catalyst

[Wade Stuart]

On Wed, Dec 9, 2009 at 1:27 AM, Bill Moseley <moseley at hank.org> wrote:

>
>
> On Tue, Dec 8, 2009 at 8:32 PM, Bill Moseley <moseley at hank.org> wrote:
>
>>
>>  The UTF8 flag doesn't mean anything more than
>>> any of the other SV flags.
>>
>>
>> But the flag on indicates the the string was decoded.
>>
>
> Obviously, that's not the only way to get that flag set.  What I meant was
> if the flag is on I'm pretty sure I need to encode it before sending out =
on
> the wire.  Yes, all text needs to be encoded, even if the flag is not set=
 --
> but at the time the engine is setting the length all that can be checked =
is
> the flag.
>
> Probably a better solution is to look at the content type -- or make
> decoding and encoding core in Catalyst so that it's just another part of =
the
> request cycle.  Isn't that the problem here?  That it's not handled and t=
hus
> the need to try and fix by using bytes::length?
>
>
>
>
>>   And that implies that it needs to be encoded.  And if I don't know what
>> encoding to use then it's time to throw an exception.
>>
>> That's why it seems like the Engine should throw an exception if the utf8
>> flag is set when it's time to get the length.  Because the encoding is n=
ot
>> known so it's impossible to know the encoded byte length.
>>
>>
>>
>>
How about making it skip that code for default behavior and a config var
check to re-enable the backcompat behavior with bytes::length.  Seems like a
quick win-win.  Make a strong note in the changelog/release notes and if old
apps break,  you have the option to fix them or set the config flag to
enable the hackish-hack-hack.

Thanks!

Wade Stuart

Phone:  917-363-6164
IM: SpaceMuscles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20091210/cecf9=
1a8/attachment.htm