Re: param quirk

[Michael Blakeley]

At 3:37 PM -0700 8/16/2000, Michael Blakeley wrote:

  But the problem is that
   [EMAIL PROTECTED]
also comes through as
   email=mike [EMAIL PROTECTED]
instead of
   [EMAIL PROTECTED]

Never mind; my test wasn't correct. Apparently wget decodes the input 
URL before performing the fetch (it's lost some credibility with me). 
Just for the record, the better test is to telnet directly to the 
server port:

$ telnet localhost 80

GET /test?email=foo%2bbar HTTP/1.0

HTTP/1.1 200 OK
Server: Apache/1.3.9 (Unix) mod_perl/1.24

email=foo+bar

$ telnet localhost 80

GET /test?email=foo+bar HTTP/1.0

HTTP/1.1 200 OK
Server: Apache/1.3.9 (Unix) mod_perl/1.24

email=foo bar

The "test" handler is pretty obvious, but here's the heart of it:

my $tab = $r-{apr}-parms;
for (keys %$tab) {
 $r-print("$_=" . $tab-{$_} . "\n");
}

Anyway, I wanted to close the loop in case anyone was wondering about 
my sanity (it comes and goes).

-- Mike

param quirk

[Michael Blakeley]

It seems that Apache::Request::param returns inputs like
[EMAIL PROTECTED]
as
email=mike [EMAIL PROTECTED]

I can live with that, since + is a reserved character and lots of 
apps expect '+' to read as ' '. But the problem is that
[EMAIL PROTECTED]
also comes through as
email=mike [EMAIL PROTECTED]
instead of
[EMAIL PROTECTED]

Now, this seems like double-unescaping to me. I've been looking 
through the source to see if I can spot the bug, but maybe someone 
out there already knows? where to look?

thanks,
-- Mike