Rasmus Lerdorf wrote: > Jason Barnett wrote: >>> the wrong permissions. Why does apache not server the 403 on the php >>> page? Maybe this is better off in the apache list. >> >> Yeah, this is really better on an Apache list... but... >> http://httpd.apache.org/docs/mod/core.html#errordocument > > No, it has nothing to do with Apache. Apache doesn't open the file, PHP > does. You could argue that PHP should try to throw a 403 on a > permissions error, but the problem is that it is really too late in the > game to do so once we get to the content handler phase where PHP lives. > It could be hacked to do it a number of ways, but it wouldn't be pretty > and it wouldn't be very consistent either since we would have to only do > it if no output has been sent on the request yet. So a sub-request or > an auto-prepend would both change the behaviour. Actually, as the naive PHP programmer, I'd only want it to happen if it were "the file matching the original URI request" rather than "no content sent to the browser yet" Consider: <?php /* index.php */ require 'connect.inc'; require 'authenticate.inc'; ?> If index.php is not readable, then a 403 would make sense to me. But suppose index.php is readable, and so is connect.inc, but *not* authenticate.inc: chmod 644 index.php chmod 644 connect.inc chmod 000 authenticate.inc If authenticate.inc were not readable, a 403 sent because PHP can't read one of those files would just be morally wrong, even if no content went to the browser yet. Because it's real likely that *I* am sending a 403 as part of my script in authenticate.inc, using HTTP Basic Authentication as described in the PHP manual. You'd be confusing the HELL out of me to have PHP sending out a 403 because it couldn't read the included file after it already managed to read index.php and connect.inc At that point, the problem is not that the page is not readable, but some portion of PHP script is not readable, and I would expect PHP to know the difference. That may be an unreasonable expectation on my part, and maybe I'm just spoiled by PHP's exemplary behaviour in the past of telling me exactly which file where I managed to screw up, but that's what I expect from PHP these days. :-) I suspect that this makes it even more of a hack to try to do, and even less likely, if it's even possible to be less likely, that it will be done some day. Throw in some mod_rewrite stuff and having PHP figure out when to do 403, and when to complain that it can't read a file, will be probably be *way* too much hackery. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
