The path info technique is moderately well known.  I thought I'd seen an
account of it at, and I would have given you the link, but
when I looked just now I couldn't find it. Anyway, this is roughly how it

You can add all kinds of stuff at the end of a url pointing to your php
script and the php still gets run e.g.

will still cause myscript.php to be run.  Anything appearing after the path
name is know as the path info and is available in a pre-defined global
variable $PATH_INFO, (at least with Apache).  In this example $PATH_INFO
would be "/this/and/thatand_the_other", (note the / at the front).

Basic Technique
So you can use PATH_INFO to communicate with your script from a link without
using a GET string e.g.
instead of :  /myscript.php?search=findthis, you could just have

With the first, "GET" syntax, php automatically sets $search to "findthis".
If you use the second, path info syntax instead, then you have to do a bit
more work to get the value into the variable you want.  In this case, you
would do something like:

list($null,$search) = explode('/',$PATH_INFO);

>From this line on, it's exactly as if $search was set from the GET

(The $null variable is simply there to "use up" the empty variable that
explode assigns for what appears before the first /, it is only necessary
because I use list() syntax to do all the work of unpacking and assignment
in one line.  list($search) = explode('/',substr($PATH_INFO,1)); would be an
alternative that avoids this dummy variable.)

You can pass any number of parameters, but your script needs to know what
variables need to be set and in what order, which it doesn't have to do
with  the GET, since the names of the variables are passed as well as their
values on a GET. For example, I've had urls that look like something like
as a replacement for


To unpack the PATH_INFO version in this case, I use the following code:

list($null,$section_code,$type_code,$manufacturer_code) =

That's about all there is to it.

Eliminating the .php
There is a further refinement that I like, which is to get rid of the .php
on the end of the script name.  So
instead of    /myscript.php/this  you have just /myscript/this, or in my
last example :
/product/cookers/range/belling.   To achieve this you need to tell your
web-server that it should treat files with no extension as if they were php
files.  If you run Apache, you need the following directive in the
configuration file.

DefaultType application/x-httpd-php

(Don't assume I've got the syntax exactly right, check it!)

You can set it across your whole server, just some virtual servers or
individual directories.  This tells Apache that if a file has no "type" i.e.
no extension, treat it as php.

The Advantages
Why bother using PATH_INFO, since it is extra work?

1. Elegant URLs
Like you, I much prefer elegant urls.  My reasoning is that the "location"
of a page has an extremely prominent position within any browser, so it
ought to be made as attractive, straightforward and unfrightening for the
user as possible.  It's as much a part of the design as the rest of the
page.   Whenever I see horrendous urls, (and some of the supposedly most
professional sites are the worst), I get a bad taste in my mouth.  I
immediately assume that if the location of the page has such unnecessary
geekery, there is probably a lot more unnecessary geekery to follow on the
body of the page...

2. Search Engines
An often quoted reason for using PATH_INFO is that search engines will not
follow links which include GET data, whereas they will always follow
PATH_INFO based links since there is no way they can distinguish them from
"real" static links.  In principle, this means that you can get every page
of search results indexed and treated as if it were an individual static
page by the search engine.  You just need "hidden" path info based links on
your pages that point to searches for "all" or various sub-sets of the
possible results.  But search engine placing is a black art, so don't take
my word for it ;)

3. Usability
Another point, is PATH_INFO urls are generally easy to
remember/bookmark/manage, since they have a simpler format and will always
use less characters than the GET version.  They are, for example, much more
likely to be fully visible in the browser's message toolbar during hovers
over links.

4. Multi-Output Services
There is a more subtle long-term advantage in eliminating the GET portion of
your urls.  Pure "PATH_INFO" urls are inherently more standards compliant
than urls with GET information.  They are significantly more likely to fit
in with non-html urls, e.g. satisfying wap or xml requests for "data" from a
"service" without changing the "addressing" of the service. You could
publish the fact that urls of the form mysite/product/cookers/range/belling
always return information about Belling range cookers, with the form in
which the data is returned,  html, wml,  xml or whatever just depending on
the request type.  The basic address of the data is the same, regardless of
the format requested.

Before anyone jumps on my back for suggesting GET syntax is non-standard,
let me point out that it's always going to be true that an "address" format
with only one delimiter i.e. '/', is going to be more easily ported than an
address format with four i.e. /, ?, = and &.

5. Advanced Techniques
There are loads of simple but powerful techniques you can invent  if you
combine PATH_INFO with the DefaultType technique.

For instance, you could take an existing static site and turn it into a
fully dynamic php site with minimal changes.  You might want to add standard
headers/footers to turn a framed into a frameless site, or to add
sophisticated database controlled user access control, all without changing
any of the static pages or their cross-links.  How?  Well you rename the
static site's directories and then put php scripts in with the old name of
the directory.  Then all requests for pages within the original directory
are immediately routed to the php script.  That script can then use
PATH_INFO to find what page was actually requested, read in the html of the
static page, manipulate it,  e.g. "including" new headers/footers, and then
return the modified html just as if it was the original static page! It's a
lot less work than modifying all the static pages, and a lot more friendly
if you want the page contents to be maintained by html designers with no php

General Problems

1. Caching
If you are using PATH_INFO, you should watch out for caching issues.  I'm
not quite sure how it works, (can anyone help explain?), but it seems that
browsers and other cache-ers (e.g. proxy server caches), try and make sure
they do not cache dynamic pages e.g. search results.  I suspect that they
identify dynamic pages by POST requests or presence of GET information,
neither of which are there if you use PATH_INFO.  I believe that means you
can end up with users getting out of date results if they follow a PATH_INFO
link at a later date. The results will be served up from cache instead of
being re-generated.

There's a pretty simple failsafe solution.  You just have to make sure you
send out explicit headers to prevent cache-ing e.g. insert the following
php, (or call a function with this code), at the top of every script.

header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . "GMT");
header("Cache-Control: no-cache,must-revalidate");
header("Pragma: no-cache");

2. Invisible php
One regret I have about developing sites which fully use these techniques,
is that it can end up being completely impossible for anyone, including the
robots that collect tool-usage data, to know that the site uses php.  If I
was using asp, perl, ColdFusion, Oracle, etc. I would consider that
desirable ;).  But it does seem a bit unfair on php that it can be so good
that ends up completely invisible!

I don't know how many people are using this technique, (how can anyone
tell?), but it's even possible that this is part of the reason why php sites
are, apparently, not growing as fast relative to other technologies as they
used to.

Sample Site
======== uses PATH_INFO quite a bit.  In particular, it
has php scripts which produce dynamic images, (try the "League Tables" and
"Cup Competitions" options).  These dynamic image scripts receive their
control information i.e. where to find the data to display, via PATH_INFO.
That makes it easy to change the image displayed without reloading the
page.  There's a little bit of Javascript that runs when the user changes
their selection to tweak the image url (location), and change the
image-generating scripts "parameters".

By the way, if anyone is interested in bits of this site's code for another
sports results site, let me know and I'll see if the client will let me
release some or all of the code.  It took me more than a month's work, and,
IMHO, it has some semi-cute features.  It'd be a shame if it was only ever
used for a few hundred London youth soccer teams, when it could be easily
converted to handle league/cup fixtures and results for basketball,
baseball, ice-hockey or whatever

Another of my sites that's pretty much path info throughout, but which
you'll probably find more entertaining is, an
online gaming site.  There are free games, (flash based), and real money to
be won if you sign up for the prize games, so even though the techniques are
less obvious, (most of it runs in windows without location bars), you might
find it more interesting!

Hope this helps.  If you, or anyone else, find these notes useful, please
drop me a mail and I'll think about putting a proper article somewhere or



Navid Yar wrote:

> George,
> Good point. I actually like your idea a lot. I have never thought about
> using $SCRIPT_NAME.
> You also mentioned using "$PATH_INFO to implement elegant (and
> search-engine safe) urls..." below. Can you give me a couple of examples
> of how I might do this? I always hated the GET strings at the end of the
> url. Sometimes I redirect a user to the same page two times just to get
> rid of the trailing GET string. I know that's a bad way of doing it, but
> it was a temporary thing until I could find a way around it. I would
> really appreciate your help on this one. Thanks...
> Navid
> -----Original Message-----
> From: George Whiffen [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 18, 2002 7:09 AM
> To: Navid Yar
> Subject: Re: [PHP] form submission error trapping
> Navid,
> $SCRIPT_NAME is sometimes a safer alternative than $PHP_SELF.
> The difference is that $PHP_SELF includes $PATH_INFO while $SCRIPT_NAME
> is
> just the name of the actual script running.
> This becomes particularly important if you use $PATH_INFO to implement
> elegant (and search-engine safe) urls e.g. /search/products/myproduct
> rather
> than /search.php?category=products&key=myproduct.
> George
> Navid Yar wrote:
> > Simply, to send a form to itself, you can use a special variable
> called
> > $PHP_SELF. Here's an example of how to use it:
> >
> > if ($somevalue) {
> >    header("Location: $PHP_SELF");
> > } else {
> >    execute some other code...
> > }
> >
> > Here, if $somevalue holds true, it will call itself and reload the
> same
> > script/file. This code is not very useful at all, but it gets the
> point
> > across. If you wanted to pass GET variables to this, then you could
> > easily say:
> >
> > header("Location: $PHP_SELF?var=value&var2=value2&var3=value3");
> >
> > ...and so on. You can also use this approach with Sessions if you
> wanted
> > to turn the values back over to the form page, assuming you had two
> > pages: one for the form, and one for form checking and entry into a
> > database. There are several ways to check forms, whether you want it
> on
> > one page or span it out to several pages. You just need to be creative
> > in what tools are avaiable to you. Here is an example of how you can
> > pass session values:
> >
> > header("Location: some_file.php?<?=SID?>");
> >
> > Here, whatever variables you've registered in session_register() will
> be
> > passed to the php page you specify, in this case some_file.php. Hope
> > this helps. Have fun, and happy coding.  :)

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to