CGI of url-encoded query string

glendeni has asked for the wisdom of the Perl Monks concerning the following question:

On a website I run I've recently noted in the apache error logs a number of url-encoded requests ala

  GET /cgi-bin/script.cgi?c%3D1%3Bu%3D1%3B...
[download]

which causes the script to fail, whereas using the comparable query string

  GET /cgi-bin/script.cgi?c=1;u=1;...
[download]

is successful. My website uses perl v5.8.0 and apache 2.0.46, but I tested this on my less dated home server using perl 5.18.2 and apache 2.4.7 with the same result.

The perl script uses

  use CGI ;
  my $query = new CGI;
  $cparam = $query->param('c');
  $uparam = $query->param('u');
[download]

Should this be happening? I had assumed the CGI module would handle url-encoded input. Is there a way to treat this?

I should add that the url-encoded cases are very rare and may come from some kind of bot instead of a human user.

LATER - decided that the submitted query string is invalid and should not be expected to be processed by CGI since query string delimiters have been encoded, making parsing of parameter name and value impossible. Will now try to delete this post, but leaving this in case I can't figure that out

Comment on CGI of url-encoded query string Select or Download Code

Replies are listed 'Best First'.
Re: CGI of url-encoded query string by afoken (Chancellor) on Nov 24, 2015 at 07:04 UTC
LATER - decided that the submitted query string is invalid and should not be expected to be processed by CGI . Will now try to delete this post, but leaving this in case I can't figure that out. Please don't! Leave your post here, so that others can find it and learn from it. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply]
Re: CGI of url-encoded query string by Your Mother (Archbishop) on Nov 24, 2015 at 18:18 UTC
FWIW, I think your conclusion is right. They're invalid because they are double encoded. Your logs will show the plain, human readable query strings, not encoded strings, which means the literal query string coming from the client's request actually looks like `c%253D1%253Bu%253D1...`	[reply] [d/l]