Or put them outside of the web server's document hierarchy. 

I'd feel safer with that than naming them with a .php extension. If they 
can still be executed by PHP using a GET request, then something could 
still be output to a user's browser. (Likely unintentionally, of course, 
but still...) Plus, if they're large enough include files that include a 
whack of other files, then why bother wasting CPU cycles on something that 
doesn't need to be processed in the first place? Just send back a DENY and 
get it over with.

Personally, I stick 'em in an include directory and set up a .htaccess with 
something like

<Files ~ "\.inc$">
    Order allow,deny
    Deny from all

I like having everything like that in the web server's directory if 
possible. Makes distributing stuff easier when you don't have to tell 
users, "Now copy all .inc files to /some/path and set PHP's include_path to 
/some/path, and make sure the server can read that directory..."


Michael Kimsal wrote:

> On that same topic, *why* do people name files with both .inc and .php?
>   Your .inc file has PHP code in it, right?  Why not just call it .php and
> spare the server reconfiguration.  If knowing which files are "include"
> files (long time since I've made that distinction!) just prepend
> them with inc_ or put them all in an includes/ directory.
> You hit a raw nerve there J Smith.  :)

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

Reply via email to