QUERY_STRING parsing and '$value =~ tr/+/ /;' treatment

[Yohan N Leder]

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) ?

 

[Stan R.]

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

 

[Yohan N Leder]

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.


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.

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.

 

[Yohan N Leder]

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 )

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.

 

[Yohan N Leder]

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?


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

Yes, Sinan, the mistake was possible, effectively... But if I told about
a piece of Perl code involved in URL decoding, talking about base64
data, it was because I didn't realized that URL treatment was not open
to other type of data than the URLencoded ones. And, by that way, I was
surprised about this tr/+/ / treatment.

Also, and to show you the reason why of my question : recently, I
initiated a thread here, titled 'How to delete temporary file after
displaying in browser ?'... The possibility to pass base64 encoded data
through url was suggested at a point, even if url length limitation was
also expressed.

Well, have a good night (00:14 here) and don't worry : the essential is
to generate communication (sometimes useful, sometimes not ; not any
importance) ;-)