httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: New charset support breaks existing app charset/utf8 support
Date Tue, 19 Apr 2005 00:20:03 GMT
Markus Wichitill <mawic@gmx.de> writes:

[...]

> Some more points:
>
> - Perl 5.6 may have the beginnings of UTF-8 support built-in, but it's
> buggy and there's no interface to use that functionality, so for all
> intents and purposes it doesn't support UTF-8. I'm not sure if that
> actually happens now, but you really don't want to set the flag under
> that version. 
>
> - Even Perl 5.8.0 - 5.8.2 are too buggy to be safely used with utf8-flagged
> scalars.

Would it make sense to not set the SV's UTF-8 flag for perl < 5.8.0?
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.
This would be a compile-time check, so it wouldn't hurt performance.
Making it configurable at run-time will either slow things down or add 
more bloated code.  And of course it might hurt your own code, because 
that's another portability condition you may need to work around.

> - Analyzing the paramters for encoding, when that's not required in
> many cases, seems wasteful from a performance perspective. And
> performance was always an important aspect of apreq.

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.  Besides, performance is something we can retune as the situation 
improves.  At the moment, I think it's better to spend some time validating 
non-ascii form data, but whoever's doing apreq in the future can
optimize that away by just assuming that data is utf8.

-- 
Joe Schaefer


Mime
View raw message