in reply to Re: Re: cgi redirect (again)
in thread cgi redirect (again)

Aha! I found the culprit! You were spot on, although slightly confused. Apache does notice the status header of an internal redirect. Here's the code: 
        location = ap_table_get(r->headers_out, "Location"); 
 
        if (location && location[0] == '/' && r->status == 200) {

[download]
So if there's a status, it has to be "200". Any other status, and the code falls through to sending the header out to the client instead (an external redirect).

And there appears to be no-way to force a 200 status using CGI.pm's "redirect". {sigh}

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

update: Ahh. I was wrong about CGI.pm. You can use 
print redirect(-uri => "/foo", -status => 200);

[download]

Replies are listed 'Best First'.
Re: •Re: Re: Re: cgi redirect (again)
by EvdB (Deacon) on Dec 03, 2002 at 19:56 UTC
    Super, always pleased to learn new stuff.

    So what is happening is that the CGI.pm is sending headers to Apache to send back to the client. However Apache notices that the status is 200 and that there is a Location header and decides to issue a new request through itself for this location. So until the new location's data is grabbed and is ready to go back nothing is sent to the client making this an internal, as opposed to external, redirect.

    So without forcing a status of 200 CGI.pm redirect would send back a status of 302 (Moved Temporarily) which Apache would send on to the brower to deal with.

    I believe I am clear an this now, thanks for the clarification.

[reply]
[d/l]

In Section Seekers of Perl Wisdom