KEVIN ZEMBOWER wrote:
> If you go to this URL, you'll get a broken version of the main home
> page on our site: http://www.hcpartnership.org/index.php/search . We
> can't understand this, because 'index.php' is a file, not a
> directory. (The correct web page is just at
> http://www.hcpartnership.org/index.php.)

Hopefully someone with more experience than me will answer this, but I did some
research and thought I'd post my findings.

First of all, I tested this on one of my servers and the same thing happened.  I
requested an existing PHP file and appended another directory name after it, and got
the page I requested.  It was "broken" the same way your example is, because the
page used relative URI's for the src attribute of all the img tags, and the browser
believed it was in a different directory than it really was, and requested images
that did not exist.

The output of php_info() showed this additional information to be in the
$_SERVER['PATH_INFO'] variable.  After doing some research I discovered that
PATH_INFO is part of the CGI spec.  Web servers will make this additional
information available to the CGI script as an environment variable.  Further reading
indicated to me that Apache passes all of this information to a script handler and
the script handler decides what to do with it.  Apache 2.x provides a configuration
directive to force it to return a 404 when given a path like the above, but 1.x does
not.  I believe that you can disable this behavior in PHP by configuring it with
"--disable-path-info-check".  I'd be interested to know if this does correct this.
I personally see it as a problem for people who aren't intending to use it and use
relative URI's for images.  Not that it would come up very often, but still...

More info:
http://www.php.net/manual/en/configure.php
http://httpd.apache.org/docs-2.0/en/mod/core.html#acceptpathinfo

HTH

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to