Re: [PHP] Understanding behavior of 'directories below files'
This behavior is used to make search engine friendly urls. If you don't want the broken images, add this to the head section: base href=http://www.hcpartnership.org/; KEVIN ZEMBOWER wrote --- napísal:: I'm a system administrator who's dabbled a bit in PHP, but am not very experienced in it. My PHP developer came to me with a behavior which neither of us can understand. 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.) Here's another example: http://www.hcpartnership.org/path_test.php/search : does not generate a 404 error http://www.hcpartnership.org/path_test.html/search : generates a 404 error This is despite the fact that both of these two files are empty: www:/var/www/hcpartnership/htdocs# ls -l path* -rw-r--r--1 rmcpeak wwwadmin0 Jun 25 10:09 path_test.html -rw-r--r--1 rmcpeak wwwadmin0 Jun 25 10:10 path_test.php www:/var/www/hcpartnership/htdocs# Can anyone explain to me why this is happening? Is this a danger? Can this be turned off? Is this controlled in the .php code, in the php.ini file or in the Apache configuration, or elsewhere? We didn't even know how to describe this problem well, so our searches of the archives of this mailing list and Google weren't successful. Let me know if we overlooked something. Thanks so much for your suggestions and thoughts. -Kevin Zembower -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Understanding behavior of 'directories below files'
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
RE: [PHP] Understanding behavior of 'directories below files'
Michael, thank you for finding out this information. I think you're right on the money. Unfortunately, when I tried to implement the --disable-path-info-check on my PHP system, it didn't work. Reading the fine print at http://www.php.net/manual/en/configure.php showed: --disable-path-info-check If this is disabled, paths such as /info.php/test?a=b will fail to work. Available since PHP 4.3.0. For more information see the Apache Manual. Alas: www:/etc/php4/cgi# php4 -v 4.1.2 www:/etc/php4/cgi# which is the version with Debian 3.0 (woody). Thanks, again, for researching this and finding the answers that I couldn't. -Kevin Michael Sims [EMAIL PROTECTED] 06/25/04 12:25PM 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Understanding behavior of 'directories below files'
Just to re-enforce Michael Sims, post... * Thus wrote KEVIN ZEMBOWER: I'm a system administrator who's dabbled a bit in PHP, but am not very experienced in it. My PHP developer came to me with a behavior which neither of us can understand. 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.) This behaviour has been around (cept for iis php) since way back in the CERN httpd days. traditionally this behaviour was only known within your cgi-bin directory. But since php is ran in your document root, the behaviour has changed. The original behaviour was to issue something like: /cgi-bin/script.cgi/path/to/some/random/thing And the CGI script would be passed two extra environment variables: PATH_INFO PATH_TRANSLATED PATH_INFO would contain the string after the name of the cgi being executed PATH_TRANSLATED would be DOCUMENT_ROOT/PATH_INFO. If you followed all that I said so far, the cgi application, with super ease, could check and read a file that actually existed in the normal html document tree. Which made writing C programs a lot more easier :) Here's another example: http://www.hcpartnership.org/path_test.php/search : does not generate a 404 error http://www.hcpartnership.org/path_test.html/search : generates a 404 error Apache is smart enough to determain the difference between a .html and php script. PHP simply inherits the traditional CGI environment, and an html simplyy can't do anything with PATH_INFO, so apache just decides to say 404. Can anyone explain to me why this is happening? Is this a danger? Can this be turned off? Is this controlled in the .php code, in the php.ini file or in the Apache configuration, or elsewhere? One quick fix, i could suggest but not recomend is to add an auto_prepend_file in php that checks for $_SERVER['PATH_INFO'] and will redirect to $_SERVER['PHP_SELF']. A better solution, on the other hand, would be just to make sure your html output behaves properly, aka not define a link that goes to /index.php/search. And the best solution, depending on how active and complex your site is, is to use the quick fix and have it alert you in some way, ie using error_log(), as to let you know that you need to fix some html somewhere. We didn't even know how to describe this problem well, so our searches of the archives of this mailing list and Google weren't successful. Let me know if we overlooked something. Thanks so much for your suggestions and thoughts. I just hope my thoughts and suggestions were clear enough :) And that I didn't go overboard. Curt -- First, let me assure you that this is not one of those shady pyramid schemes you've been hearing about. No, sir. Our model is the trapezoid! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
