On Wed, Dec 9, 2009 at 1:27 AM, Bill Moseley <[email protected]> wrote:
> > > On Tue, Dec 8, 2009 at 8:32 PM, Bill Moseley <[email protected]> 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 thus > 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 not >> 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
_______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
