PHP包含文件扩展名？

Question

对于PHP中的必需/包含文件，使用.inc扩展名与.inc.php vs .php扩展名更好吗？

Answer 1

Sometimes people use the .inc extension and then do some server configuration to keep .inc files from being accessed via a web browser. This might be good, if done absolutely correctly by a knowledgeable sysadmin, but there's a better way: Any file that's not supposed to be accessed by web users should be kept outside your document root. Once these files are off the web, so to speak, you can use whatever extension you want. .php is definitely a sensible choice for syntax highlighting, general sanity, and so on.

Answer 2

Apache can sometimes (due to bugs or severe crashes) serve .php files as text (happend to me a few times on shared hosting).... I think you can use any extension you want as long as you don't store your files in a public folder.

Let's say your site is in /home/user/public_html/

create another folder /home/user/lib_php/

have the files:

(1) .../lib_php/one.class.php with

class one { 
//...
}

(2) .../lib_php/two.function.php with

function two() { 
//...
}

and you have the main index.php in /public_html

<?php 
include_once('../lib_php/one.class.php');
include_once('../lib_php/two.function.php');


$x=a; $b=two($x); $c=new one; //etc.. 

or

 
<?php
require_once('/home/user/lib_php/the.file.php'); 

This way you are taking every precaution the files are not reachable directly but can be used by your scripts...

Answer 3

My personal preference is that anything in the document root is a .php file, to indicate it's directly executable by the web server, and anything that's a library is a .inc file stored in a parallel directory, to indicate it's NOT directly executable.

My standard configuration is

/home/sites/example.com/html/ - anything here is 'safe' to expose if PHP fails and serves up raw code

/home/sites/example.com/inc/ - libraries, config files with passwords (eg the database connection class with DB credentials), etc.. Anything that shouldn't be exposed as there's no reason for it.

While you can certainly configure Apache to deny access to .inc files and keep them inside the webroot, then you're depending on Apache to keep you safe. If PHP can fail within Apache and expose your code, then the .inc blocks can ALSO fail and expose your code's innards as well.

Of course, if Apache's coughing blood all over the floor, there's no reason that the directory traversal protection can't fail as well and let someone do http://example.com/../inc/seekritpasswords.txt .

At some point you just have to accept that if something's stored anywhere on the web server, there's a possibility that a failure may allow access to the raw data and expose everything. How much time and effort you want to expend on protecting against that is up to you.