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 10:55:07 GMT
Markus Wichitill <mawic@gmx.de> writes:

> Joe Schaefer wrote:

[...]

>> 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,

Yes, the patch-level issue.

[...]

> 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. 

+1 to being enctype-agnostic.  Do you know how CGI.pm behaves here?
I think our default behavior should mimic that as much as possible.

>
>> 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.

Agreed.  So if we don't always validate, I think we need to 
decouple apreq's internal charset support from perl's.  Since
we want to encourage users to write parsers, I think
the best idea at this point is to just add another flag for
perl's UTF-8 flag.  If perl users want to set that flag 
themselves by marching through the param table, that'd be 
ok with me.

-- 
Joe Schaefer


Mime
View raw message