general/2724: a permanent redirect (status code 301) to a non-existent file produces a status code 403 (HTTP_FORBIDDEN) instead of 404 (HTTP_NOT_FOUND)

[Seth Chaiklin <se...@psy.au.dk>]

>Number:         2724
>Category:       general
>Synopsis:       a permanent redirect (status code 301) to a non-existent file produces a  status code 403 (HTTP_FORBIDDEN)  instead of 404 (HTTP_NOT_FOUND)
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Tue Jul 28 02:50:00 PDT 1998
>Last-Modified:
>Originator:     seth@psy.au.dk
>Organization:
apache
>Release:        1.3.1
>Environment:
Linux 2.0.33
>Description:
Have a permanent redirect like this (in srm.conf):

Redirect permanent /~bo http://www.psy.aau.dk

Happened that one of the redirects was to a nonexistent file.
Here is an example from the access log file, which shows
that the redirect (301) gives a "forbiddden" error (403), when in reality
it should give a "not-found" (404).

ocelot.eng.pgh.lycos.com - - [28/Jul/1998:00:52:05 +0200] "GET /~bo/staff/stats.
html HTTP/1.0" 301 242
ocelot.eng.pgh.lycos.com - - [28/Jul/1998:00:52:58 +0200] "GET /staff/stats.html
 HTTP/1.0" 403 214  

But according to src/main/http_request.c (lines 153 and 154) (version 1.3.1)

     * Note that we don't reject accesses to nonexistent files (multiviews or
     * the like may cons up a way to run the transaction anyway)...

      
>How-To-Repeat:
Have a permanent redirect to a non-existent file. (I haven't tried with
a temporary redirect...maybe the same problem?)
>Fix:
Didn't completely untangle the code after 10 minutes of trying...but the 
problem is in src/main/http_request.c  I guess the ap_internal_redirect() 
calls process_request_internal() which eventually calls directory_walk()
which calls get_path_info() and THERE is where the mistake actually comes.
I suspect the maintainer of this section of the code will see what needs
to be done.

And while I am at it....perhaps the ap_log_error() on line 251 (version 1.3.1)
in the function get_path_info() should make some indication that the failure 
was because of server configuration (as is done in mod_access) and not simply 
"failed" as it presently does.
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, ]
[you need to include <ap...@Apache.Org> in the Cc line ]
[and leave the subject line UNCHANGED.  This is not done]
[automatically because of the potential for mail loops. ]