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