To: new-httpd@hyperreal.com
Subject: unresolved internal redirect bug
In-reply-to: Your message of "Sat, 26 Oct 1996 19:55:56 PDT."
             <9610261955.aa17765@paris.ics.uci.edu>
Date: Sun, 17 Nov 1996 19:14:16 -0800
From: "Roy T. Fielding" <fielding@liege.ICS.UCI.EDU>
Message-ID: <9611171914.aa09865@paris.ics.uci.edu>
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

I consider this to be a showstopper bug because it hides bad things
from being seen, prevents 401 redirects from working, and possibly
other things which would be really hard for a user to diagnose.
At the least, I'd like someone familiar with internal redirects to say
why it isn't a showstopper bug, since it is giving me the heebie-geebies.

.....Roy

> Ok, so here's the bug
> 
>     void internal_redirect (const char *new_uri, request_rec *r)
>     {
>         request_rec *new = internal_internal_redirect(new_uri, r);
>         process_request_internal (new);
>     }
> 
> The problem is that a request on /dir/ is internally redirected to
> /dir/index.html, which properly results in a 304 Not Modified.  However,
> the r->status is not updated to reflect new->status (and anything else
> that might need to be promoted).  My first inclination was to add
> 
>         r->status = new->status;
> 
> as the last line of the above routine, but I haven't the slightest idea
> what effect (if any) this would have on the other routines using
> internal_redirect(), and there may be other parts of new that should be
> promoted to r as well.  Furthermore, given that this might get messy
> if the request_rec structure includes (or is extended to include) more
> response-applicable information, it would be nice is we had a procedure
> 
>     promote_response_status(r, new);
> 
> which updated r for us in general.  Since I'm not confidant enough with
> the internal_redirect purpose(s), would someone else like to do it?
> 
> .....Roy