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
</Files>
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..."
J
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
