|
|
Posted by Richard Lynch on 10/04/83 11:05
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
Navigation:
[Reply to this message]
|