Re: Silent removed parameters when posting UTF8

This is probably not be a perl issue as I did not have the same
version of URI and libwww-perl installed where I tested.  What version
of URI and libwww-perl did you use?  I now think that you'll see the
first behaviour with URI <= 1.35 and the later if URI is more recent.

--Gisle

On Fri, Sep 19, 2008 at 2:14 PM, Gisle Aas <[email protected]> wrote:
> I wonder if this is a bug in perl itself.  With perl-5.8.8 I get:
>
>    count=123&works=%E2%98%BA&does_not_work=&foo=bar
>
> as you showed, but with perl-5.8.9(tobe) and perl-5.10.0 I get:
>
>    count=123&works=%C3%A2%C2%98%C2%BA&does_not_work=%E2%98%BA&foo=bar
>
> so now it's the 'works' case that does_not_work but in a different way :(
>
> --Gisle
>
>
> On Fri, Sep 19, 2008 at 7:54 AM, Bill Moseley <[email protected]> wrote:
>> I have a form that posts to a service, and noticed not all
>> parameters were being posted.
>>
>> I realized my mistake of not encoding to utf8, but I'm curious why
>> this did not generate any warnings.
>>
>> I can imagine others getting caught by this, so a warning would be very
>> helpful.
>>
>> Not really sure where it should be checked -- in query_form when
>> processing the individual parameters, I suspect, but the damage seems
>> to happen when $uri->query is called:
>>
>>    $q =~ s/([^$URI::uric])/$URI::Escape::escapes{$1}/go;
>>
>> Would it not be better to issue a waring?
>>
>>
>> use HTTP::Request::Common;
>> use strict;
>> use warnings;
>> use Data::Dumper;
>> use Encode;
>>
>> my $content = {
>>    foo => 'bar',
>>    count => 123,
>>    works => encode_utf8("\x{263A}"),
>>    does_not_work => "\x{263A}",
>> };
>>
>> my $x = HTTP::Request::Common::POST(
>>    'http://localhost.com',
>>    $content,
>> );
>> print Dumper $x;
>