Hmm, can please someone confirm this? I'm afraid there is an HTTP specs
violation here, and the server in question should be fixed not the code
that generates URLs... see below for more info.
Thanks!
-------- Original Message --------
Subject: RE: mod_perl guide corrections.
Date: Fri, 9 Jun 2000 22:47:49 +0200
From: "Eric Jain" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 09, 2000 9:19 PM
> To: Eric Jain
> Subject: Re: mod_perl guide corrections.
>
>
> Eric Jain wrote:
> >
> > In
> http://thingy.kcilink.com/modperlguide/correct_headers/3_3_GET.html
> > :
> >
> > " Thus it allows the co-existence of queries from
> ordinary forms that
> > are being processed by a browser and predefined requests
> for the same
> > resource. It has one minor bug: Apache doesn't allow
> percent-escaped
> > slashes in such a query string. So instead of:
> > http://foo.com/query;BGCOLOR=blue;FGCOLOR=red;FONT=%2Ffont%2Fbla
> > you have to use:
> > http://foo.com/query;BGCOLOR=blue;FGCOLOR=red;FONT=/font/bla "
> >
> > I noticed that %2B (+) and %3F (?) wouldn't work when
> using this kind
> > of query strings, at least not on my websever. %2B would be
> > interpreted as a space, for example.
> >
> > Obviously the query string is being unescaped twice.
> >
> > One solution is to simply escape all the '%' (%25):
> >
> >
> http://foo.com/query;BGCOLOR=blue;FGCOLOR=red;FONT=%252Ffont%252Fbla
> >
> > It works :-)
>
> Eric, what you say is that one should escape only the %
> sign and there is
> no need to use the real charaacters like in the suggestion
> above? Am I right?
Nearly :-) What I actually meant was the following:
To build a proper Link:
STEP 1: Escape all special characters, as usuall:
+biotech -t?s/t -> %2Bbiotech+-t%3Fs%2Ft&area
STEP 2: Now escape a *second* time (ie replace all '%' with '%25'):
%2Bbiotech+-t%3Fs%2Ft&area -> %252Bbiotech%2520-t%253Fs%252Ft
Voilą.
Try http://biodoc.ch/de/articles;query=%252Bbiotech%2520-t%253Fs%252Ft
, and observe what appears in the query field...
> But you still have to process those to escape, so may be
> unless it's &<>
> chars you can just make them the real chars, instead of
> using the hex
> value as in a suggested solution to the problem?
'?' doesn't seem to work either. Also their might be problems with
certain proxy servers when using strange characters? The above
solution should work in any case. Only drawback: It doesn't look that
nice :-)
sub encode
{
$_ = shift;
s/([^a-zA-Z0-9_.-])/uc sprintf("%%%02x",ord($1))/eg;
s/\%/\%25/g;
return $_;
}
--
Eric Jain
