httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Wichitill <ma...@gmx.de>
Subject Re: New charset support breaks existing app charset/utf8 support
Date Tue, 19 Apr 2005 03:31:35 GMT
Joe Schaefer wrote:
> Would it make sense to not set the SV's UTF-8 flag for perl < 5.8.0?

Absolutely.

> I don't think changing the behavior within a patch-level upgrade is
> wise, so if we enable it for 5.8.3 we should enable it for 5.8.0 also.

If you insist on forcing the utf8 flags, then yes.

> And of course it might hurt your own code, because 
> that's another portability condition you may need to work around.

Are you still talking about the patch-level issue above, or my 
$apr->charset_support(0) config method proposal in general? If it's the 
latter, I don't see the logic.

> But the slowdown should only impact non-ascii data.  If there's a lot
> of that around, you probably shouldn't be url-encoding it in the first
> place. 

So you only set the utf8 flags for parameters in GETs and POSTs with
application/x-www-form-urlencoded, but not in POSTs with 
multipart/form-data. I don't even know how to efficiently work around that 
anymore. My param wrapper function has no idea what enctype the form was in, 
nor should it.

> but whoever's doing apreq in the future can
> optimize that away by just assuming that data is utf8.

Can't do that with untrusted data from the Internets, set a utf8 flag on 
invalid data, and Perl will happily crash.

Mime
View raw message