param quirk

[Michael Blakeley <mi...@blakeley.com>]

It seems that Apache::Request::param returns inputs like
	email=mike+test@blakeley.com
as
	email=mike test@blakeley.com

I can live with that, since + is a reserved character and lots of 
apps expect '+' to read as ' '. But the problem is that
	email=mike%2btest@blakeley.com
also comes through as
	email=mike test@blakeley.com
instead of
	email=mike+test@blakeley.com

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

Re: param quirk

[Michael Blakeley <mi...@blakeley.com>]

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

>  But the problem is that
>	email=mike%2btest@blakeley.com
>also comes through as
>	email=mike test@blakeley.com
>instead of
>	email=mike+test@blakeley.com

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