[28457] in Perl-Users-Digest
Perl-Users Digest, Issue: 9821 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Oct 8 18:10:17 2006
Date: Sun, 8 Oct 2006 15:10:09 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 8 Oct 2006 Volume: 10 Number: 9821
Today's topics:
QUERY_STRING parsing and '$value =~ tr/+/ /;' treatment <ynl@nsparks.net>
Re: QUERY_STRING parsing and '$value =~ tr/+/ /;' treat <1usa@llenroc.ude.invalid>
Re: QUERY_STRING parsing and '$value =~ tr/+/ /;' treat <stan@invalid.blz/hmrprint/com.com>
Re: QUERY_STRING parsing and '$value =~ tr/+/ /;' treat <segraves_f13@mindspring.com>
Re: QUERY_STRING parsing and '$value =~ tr/+/ /;' treat <1usa@llenroc.ude.invalid>
Re: QUERY_STRING parsing and '$value =~ tr/+/ /;' treat <ynl@nsparks.net>
Re: QUERY_STRING parsing and '$value =~ tr/+/ /;' treat <ynl@nsparks.net>
Re: QUERY_STRING parsing and '$value =~ tr/+/ /;' treat <1usa@llenroc.ude.invalid>
Re: Unit-testing and mock objects <benmorrow@tiscali.co.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 8 Oct 2006 19:43:55 +0200
From: Yohan N Leder <ynl@nsparks.net>
Subject: QUERY_STRING parsing and '$value =~ tr/+/ /;' treatment
Message-Id: <MPG.1f9357423e6924799898df@news.tiscali.fr>
Parsing $ENV{'QUERY_STRING'} w/o CGI.pm, it's usual to see code treating
extracted values with a "$value =~ tr/+/ /;" for 'unwebification' of the
'+' signs.
But, this kind of treatment will corrupt any QUERY_STRING content which
is not simple text (for example, I've done test on base64 data).
So, how does CGI.pm handle this ? How does it differenciates
QUERY_STRING content's values which has to be 'not treated' (e.g. like a
base64 encoded image) from the one which has to be 'treated' (e.g. like
a simple text) ?
------------------------------
Date: Sun, 08 Oct 2006 18:40:04 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: QUERY_STRING parsing and '$value =~ tr/+/ /;' treatment
Message-Id: <Xns98569544EFBD4asu1cornelledu@127.0.0.1>
Yohan N Leder <ynl@nsparks.net> wrote in
news:MPG.1f9357423e6924799898df@news.tiscali.fr:
> Parsing $ENV{'QUERY_STRING'} w/o CGI.pm, it's usual to see code
> treating extracted values with a "$value =~ tr/+/ /;" for
> 'unwebification' of the '+' signs.
In case you do not realize this, there is no real Perl content in your
question. You are asking about URL encoding/decoding. In the absence of
Perl code with which you are having problems, this is not the right
place to ask. A CGI related group would have been better.
> But, this kind of treatment will corrupt any QUERY_STRING content
> which is not simple text (for example, I've done test on base64 data).
Why are you using GET to submit possibly large amounts of data? In any
case, + signs will be unambiguously encoded as %2b in a URL encoded
string and spaces will be unambiguously encoded as + signs. First,
replace + signs with spaces, then decode the URL encoded char values.
> So, how does CGI.pm handle this ?
Given that you can look at the CGI.pm source code yourself, I am not
sure why you have to ask this here.
> How does it differenciates QUERY_STRING content's values which has to
> be 'not treated' (e.g. like a base64 encoded image) from the one which
> has to be 'treated' (e.g.like a simple text) ?
>
See above. It does not engage in the futile exercise of trying to
discern the meaning of the data passed. It uses the unescape subroutine
in <http://search.cpan.org/~lds/CGI.pm-3.25/CGI/Util.pm>
sub unescape {
shift() if @_ > 0 and (ref($_[0]) || (defined $_[1] && $_[0] eq
$CGI::DefaultClass));
my $todecode = shift;
return undef unless defined($todecode);
$todecode =~ tr/+/ /; # pluses become spaces
$EBCDIC = "\t" ne "\011";
if ($EBCDIC) {
$todecode =~ s/%([0-9a-fA-F]{2})/chr $A2E[hex($1)]/ge;
} else {
$todecode =~ s/%(?:([0-9a-fA-F]{2})|u([0-9a-fA-F]{4}))/
defined($1)? chr hex($1) : utf8_chr(hex($2))/ge;
}
return $todecode;
As you can see, first, + signs are converted to spaces, and then char
values are decoded.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: Sun, 8 Oct 2006 12:31:47 -0700
From: "Stan R." <stan@invalid.blz/hmrprint/com.com>
Subject: Re: QUERY_STRING parsing and '$value =~ tr/+/ /;' treatment
Message-Id: <egbjmv03fq@news4.newsguy.com>
A. Sinan Unur wrote:
> Why are you using GET to submit possibly large amounts of data? In any
> case, + signs will be unambiguously encoded as %2b in a URL encoded
> string and spaces will be unambiguously encoded as + signs. First,
> replace + signs with spaces, then decode the URL encoded char values.
Actually spaces may also be encoded as %20
--
Stan
------------------------------
Date: Sun, 08 Oct 2006 20:26:21 GMT
From: "Bill Segraves" <segraves_f13@mindspring.com>
Subject: Re: QUERY_STRING parsing and '$value =~ tr/+/ /;' treatment
Message-Id: <N9dWg.4706$Lv3.1062@newsread1.news.pas.earthlink.net>
"Yohan N Leder" <ynl@nsparks.net> wrote in message
news:MPG.1f9357423e6924799898df@news.tiscali.fr...
> Parsing $ENV{'QUERY_STRING'} w/o CGI.pm, it's usual to see code treating
> extracted values with a "$value =~ tr/+/ /;" for 'unwebification' of the
> '+' signs.
>
> But, this kind of treatment will corrupt any QUERY_STRING content which
> is not simple text (for example, I've done test on base64 data).
>
So, you've discovered on your own that you shouldn't use GET to submit
non-URLencoded data.
CGI.pm has the capability of handling POST submittals of non-URLencoded data
correctly. Look for the paragraph heading "Handling non-URLencoded
Arguments" in the CGI.pm documentation.
> So, how does CGI.pm handle this ?
my $data = $query->param('POSTDATA');
> How does it differenciates
> QUERY_STRING content's values which has to be 'not treated' (e.g. like a
> base64 encoded image) from the one which has to be 'treated' (e.g. like
> a simple text) ?
CGI.pm is not designed to handle non-URLencoded data in the QUERY_STRING.
Nor is your browser. To see how CGI.pm handles said data in a POST sumittal,
look for the string "POSTDATA" in the CGI.pm source code.
Cheers.
--
Bill Segraves
------------------------------
Date: Sun, 08 Oct 2006 20:41:37 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: QUERY_STRING parsing and '$value =~ tr/+/ /;' treatment
Message-Id: <Xns9856A9DFEAABBasu1cornelledu@127.0.0.1>
"Stan R." <stan@invalid.blz/hmrprint/com.com> wrote in
news:egbjmv03fq@news4.newsguy.com:
> A. Sinan Unur wrote:
>
>> Why are you using GET to submit possibly large amounts of data? In any
>> case, + signs will be unambiguously encoded as %2b in a URL encoded
>> string and spaces will be unambiguously encoded as + signs. First,
>> replace + signs with spaces, then decode the URL encoded char values.
>
> Actually spaces may also be encoded as %20
That is beside the point. All that matters for the decoding to work
correctly is to resolve + signs to spaces *first* and then do regular
decoding of the data passed.
I am still a little confused about *how* the OP invokes the CGI script.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: Sun, 8 Oct 2006 23:16:11 +0200
From: Yohan N Leder <ynl@nsparks.net>
Subject: Re: QUERY_STRING parsing and '$value =~ tr/+/ /;' treatment
Message-Id: <MPG.1f93890673505eb29898e0@news.tiscali.fr>
In article <N9dWg.4706$Lv3.1062@newsread1.news.pas.earthlink.net>,
segraves_f13@mindspring.com says...
> So, you've discovered on your own that you shouldn't use GET to submit
> non-URLencoded data.
>
OK, it's the reply to my question. Thanks !
> CGI.pm has the capability of handling POST submittals of non-URLencoded data
> correctly. Look for the paragraph heading "Handling non-URLencoded
> Arguments" in the CGI.pm documentation.
>
> > So, how does CGI.pm handle this ?
>
> my $data = $query->param('POSTDATA');
No, my question was not how to use CGI.pm, but how the CGI.pm code
handle non-URLencoded data... And you replied previously, just above.
>
> > How does it differenciates
> > QUERY_STRING content's values which has to be 'not treated' (e.g. like a
> > base64 encoded image) from the one which has to be 'treated' (e.g. like
> > a simple text) ?
>
> CGI.pm is not designed to handle non-URLencoded data in the QUERY_STRING.
> Nor is your browser. To see how CGI.pm handles said data in a POST sumittal,
> look for the string "POSTDATA" in the CGI.pm source code.
Thanks again, Bill, now all is clear.
------------------------------
Date: Sun, 8 Oct 2006 23:38:41 +0200
From: Yohan N Leder <ynl@nsparks.net>
Subject: Re: QUERY_STRING parsing and '$value =~ tr/+/ /;' treatment
Message-Id: <MPG.1f938e4a850e35139898e1@news.tiscali.fr>
In article <Xns98569544EFBD4asu1cornelledu@127.0.0.1>,
1usa@llenroc.ude.invalid says...
> In case you do not realize this, there is no real Perl content in your
> question. You are asking about URL encoding/decoding. In the absence of
> Perl code with which you are having problems, this is not the right
> place to ask. A CGI related group would have been better.
So, '$value =~ tr/+/ /;' and CGI.pm code are not Perl ? Very funny, your
joke :o)
> Why are you using GET to submit possibly large amounts of data?
Who told about 'large' ? Not me, I just spoke about base64 data, which,
as you know, can be 'not large'.
R0lGODlhAQABAIAAAP8AAAAAACH5BAAAAAAALAAAAAABAAEAAAICRAEAOw==
> In any case, + signs will be unambiguously encoded as %2b in a URL encoded
> string and spaces will be unambiguously encoded as + signs. First,
> replace + signs with spaces, then decode the URL encoded char values.
>
The question was not 'how to handle URLencoded data', but about non-
URLencoded data... And Bill S. replied pertinently : GET is not for non-
URLencoded data.
> Given that you can look at the CGI.pm source code yourself, I am not
> sure why you have to ask this here.
>
Of course, everybody can always do without the others, but it may help
to gain time : thanks again for the clever reply of Bill S. which save
me some times for finding that non-URLencoded data is not considered by
CGI.pm in the framework of QUERY_STRING parsing.
> See above. It does not engage in the futile exercise of trying to
> discern the meaning of the data passed. It uses the unescape subroutine
> in <http://search.cpan.org/~lds/CGI.pm-3.25/CGI/Util.pm>
> As you can see, first, + signs are converted to spaces, and then char
> values are decoded.
I know this and don't have any question about URLencoded data with or
without CGI.pm
Thanks, at least for your time.
------------------------------
Date: Sun, 08 Oct 2006 21:57:06 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: QUERY_STRING parsing and '$value =~ tr/+/ /;' treatment
Message-Id: <Xns9856B6AC6C4C6asu1cornelledu@127.0.0.1>
Yohan N Leder <ynl@nsparks.net> wrote in
news:MPG.1f938e4a850e35139898e1@news.tiscali.fr:
> In article <Xns98569544EFBD4asu1cornelledu@127.0.0.1>,
> 1usa@llenroc.ude.invalid says...
...
>> In any case, + signs will be unambiguously encoded as %2b in a URL
>> encoded string and spaces will be unambiguously encoded as + signs.
>> First, replace + signs with spaces, then decode the URL encoded char
>> values.
>>
>
> The question was not 'how to handle URLencoded data', but about non-
> URLencoded data...
Ahem ... The fact that you were talking about replacing + signs with
spaces led me to believe that you were talking about URL encoded data.
If the data were not URL encoded why would mention one of the steps
involved in URL decoding it?
>> Given that you can look at the CGI.pm source code yourself, I am not
>> sure why you have to ask this here.
>>
>
> Of course, everybody can always do without the others, but it may help
> to gain time : thanks again for the clever reply of Bill S. which save
> me some times for finding that non-URLencoded data is not considered
> by CGI.pm in the framework of QUERY_STRING parsing.
Again, this is nothing specific to Perl or CGI.pm. QUERY_STRING is
supposed to be in URL encoded format which is why all CGI libraries in
any language start by decoding it.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: Sun, 8 Oct 2006 00:12:00 +0100
From: Ben Morrow <benmorrow@tiscali.co.uk>
Subject: Re: Unit-testing and mock objects
Message-Id: <0rolv3-8lc.ln1@osiris.mauzo.dyndns.org>
Quoth "jmv" <eugene.morozov@gmail.com>:
>
> Ben Morrow wrote:
> > Quoth "jmv" <eugene.morozov@gmail.com>:
> > [snip]
> > A search on CPAN for 'mock' reveals Test::MockModule. Is this the sort
> > of thing you mean?
>
> Thank you, I didn't see this module. But I'm afraid it wouldn't work.
> I've tried Test::MockObject
This is no good. You're not using objects, just simple exported subs.
> and Sub::Override and they doesn't handle
> this situation (overriding subs in module B which is used by module A
> which is used by unit-test).
You have to mock the sub in the module that uses it, not the one it
originated from. That is, if you have
package AA;
sub foo {
return 'foo';
}
and
package BB;
use AA;
sub bar {
return 'bar' . foo;
}
(Exporter &c. omitted for clarity) then you need
use Test::MockModule;
{
my $M = Test::MockModule->new('BB');
$M->mock(foo => sub { return 'baz' });
# tests
}
in your test file. I can see this may be a pain if you have a sub that
is imported all over the place and you want to mock it the same
everywhere; it should be a small matter of programming to run through
the symbol table and find everywhere this sub has been exported to...
Ben
--
You poor take courage, you rich take care:
The Earth was made a common treasury for everyone to share
All things in common, all people one. [benmorrow@tiscali.co.uk]
'We come in peace'---the order came to cut them down.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 9821
***************************************
