Ahhhh! Now we see the question! Why doesn't it yield 403 like it "should"
First and foremost, use php.ini or httpd.conf or .htaccess to *NOT* let PHP send error messages OF ANY KIND to the browser on a production site.
[You could also use ini_set within a script if the file in question is to be include'd into other files.]
You should do this anyway.
Admittedly, your server still behaves not quite like you want, as *.html yields a 403 response, and *.php yields a 200 response, and a page of no content. But at least the Bad Guys don't see your server internals.
I don't think there's any way you can configure Apache to pre-empt the PHP trying to read the file -- though I presume Apache *could* be altered to behave that way... Except it would be rather difficult for Apache to 'know' a priori what User PHP runs as, given suexec, CGI setups, etc...
Depending on your application, you might be able to "wrap" all the access to files through a known good PHP file, and then use PHP error handling (http://php.net/set_error_handler) to determine if this error occurred, and then send a 403 header.
Probably an Apache list would be better suited to knowing for sure any way around this... You could maybe tweak the PHP source to detect this condition and send 403 instead of trying to include() the file, which is what it seems to be doing.
Yeah, thanks all. I usually have error logging off, but enabled it from time to time when hunting down bugs (and forget to add it back).
Anyway, I guess I'll have to deal with just blank pages coming up in the event of a .php 403... not a big deal really, I just prefer constancy.
I still don't really get why apache hands parsing off to php when it knows it doesn't have read access to the file, but I'll save that for another list!
Thanks again. -J
-- Jason Morehouse Vendorama - Create your own online store http://www.vendorama.com
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
