[Techtalk] apache URL "look back"

Almut Behrens almut-behrens at gmx.net
Wed Jun 18 23:31:13 EST 2003

On Wed, Jun 18, 2003 at 11:24:53AM -0700, Kai MacTane wrote:
> At 6/17/03 08:55 PM , Emma Jane Hogbin wrote:
> >I'm having a problem getting the URL look back working on one server. If I
> >try this installation:
> >
> >        http://megatron.utm.utoronto.ca/~cell/cell.php/class/28
> >(and yes the URL is right -- if you remove /class/28 you'll see the "base"
> >file)
> >it doesn't work, but this one:
> >
> >        http://lang.utoronto.ca/dev/cell.php/class/28
> >is fine.
> Couple of thoughts:
> 1) Could your cell.php be having trouble parsing the ~ in the request
>    URI string?

just another thought, extending the above. The code fragment to extract
the "parameters" (i.e. the "/class/28" here) from the URI is often
implemented as follows:

  $uri    = $_SERVER["REQUEST_URI"];
  $script = $_SERVER["SCRIPT_NAME"];
  $uri = ereg_replace("^$script", "", $uri);

which is supposed to remove the stuff you're not interested in at the
beginning of the URI (/dev/cell.php or /~cell/cell.php). Basically,
this approach is absolutely correct, as it would normally work
independently of which path-prefix you have.

With the above URIs, the script's environment would contain either




In both cases, removing the value of SCRIPT_NAME from REQUEST_URI would
leave just "/class/28", which you can then split up further...

The subtle problem is that some browsers (wget for example, IIRC)
URI-encode the ~ in the request, in which case you'd get


from apache's script environment. If the script doesn't unencode the
%7E back to ~, the above regex substitution won't take place...

Even if this is not the problem in your particular case, it's something
to be aware of -- if you want your site to work with any browser.


More information about the Techtalk mailing list