Mailing List Archive

Andy sent me this snippit of code which is probably the cause of the
local redirects failing..

> mod_cgi.c, cgi_handler(), about line 310:
>
> if (location && location[0] == '/' && r->status == 200) {
> ...
> internal_redirect (location, r);
> }

The "&& r->status == 200" looks wrong at first glance. If Apache
follows the logic of the old .6.5 code then the status gets set
to 302 (or whatever number it is) when script headers are read
but no explicit status line is read.

So shouldn't the check be for "301" or "302".

A 301 "moved permanently" makes little sense in terms of a local
redirect so, perhaphs it's just "302" that needs to be covered.

Change "200" to "302" ?

rob

Rob, the way you trigger an internal redirect from a CGI script is
(and always has been) to have the script write a location header
*without* setting explicit Status --- the only point in setting
Status is if you want the revised Status to get all the way back
to the client. Failing to perform a redirect *unless* status was
changed (as you suggest) would break a whole lot of scripts,
including a bunch here.

rst

> Rob, the way you trigger an internal redirect from a CGI script is
> (and always has been) to have the script write a location header
> *without* setting explicit Status

But it doesn't seem to work.

I just tried it

print "Location: /Announce\r\n\r\n";

and it returns a 302 to the client.

I thought (but might be wrong) that 0.6.5 would do an internal redirect
regardless of the number of headers, but as long as there was a
Location line in there somewhere.

I can't duplicate the problem. The two-line script included below
works properly for me (i.e., does the redirect internally) --- note
it is just the line you gave, with a slightly different URL, and a
#! trigger line.

NB if you really are redirection to "/Announce", and that's a
directory, you will get a redirect to "/Announce/", but that's got
nothing to do with CGI; it's just the usual redirect to append the
'/', to get relative URLs in the directory listings right. If that's
what's happening, you should try redirecting to "/Announce/"
directly...

The script:

#! /usr/local/bin/perl
print "Location: /xperimental/foo.txt\r\n\r\n"

> Rob, the way you trigger an internal redirect from a CGI script is
> (and always has been) to have the script write a location header
> *without* setting explicit Status --- the only point in setting
> Status is if you want the revised Status to get all the way back
> to the client. Failing to perform a redirect *unless* status was
> changed (as you suggest) would break a whole lot of scripts,
> including a bunch here.

I'm pretty sure I did the code for .0.6 which handled the Location:
line from scripts (and asis as a result). From what I remember
(without going to the code for reference), seeing a "Location"
header changed the status of the response to 302 (unless that
had been overridden by an earlier Status line). Apache then only
looked if a "location" had been seen, then did a local redirect if
it started with a "/".

the result was that any script (+ asis) redirect would do a local
redirect if the destination was local.

Perhaps my memory is a blur on this. I'm too busy with other things
these days to check old and new code for differences.

What I've seen certainly took me be surprise and wasn't what I was
expecting or what I though looked correct.

What I think apache should be doing is..

if a "Location:" header is seen (alone or with other headers), and the
destination starts with a "/", then do a local redirect to it... nothing
more elaborate than that.

The reason this is now an issue is that a user tried to do a local
redirect from an asis file, but couldn't.

I made an earlier error with my

print "Location: /Announce\r\n\r\n";

example. That does work. It was missing a trailing "/". Doh.

rob

> I can't duplicate the problem. The two-line script included below

Yup that was a dumb mistake which I just noticed, but I think there
still might be a problem with the way local redirects are detected.

Did internal redirects from an asis file ever work? (It doesn't now.)

No, they didn't. (In any case, it seems a bit silly to do this...
the same effect can be achieved by simply making a link to the target
file).

rst

> Did internal redirects from an asis file ever work? (It doesn't now.)
>
> No, they didn't. (In any case, it seems a bit silly to do this...
> the same effect can be achieved by simply making a link to the target
> file).

There are good reasons for needing this. See the bug report email where
someone needs to redefine an index to be a script, without allowing
CGI outside of ScriptAliased area. He can achieve this with asis, but
it costs 1 external redirect and the URL users see is in the ScriptAlias
dir where he doesn't want it.

"asis" was originally written to behaves as if it were script output. It
no longer does.

--
http://nqcd.lanl.gov/~hartill/
Welcome to the information superhighway, with its super-potholes and
never ending but ever shifting roadworks.

"asis" was originally written to behaves as if it were script output. It
no longer does.

Rob, I'll say it again. Your original asis code did *not* do internal
redirects under any circumstances. Check the code and see for yourself.
You are requesting a new feature, and a fairly dubious one at that.
-1 until after 1.0.

rst

> Rob, I'll say it again. Your original asis code did *not* do internal
> redirects under any circumstances. Check the code and see for yourself.
> You are requesting a new feature, and a fairly dubious one at that.
> -1 until after 1.0.

Okay, if that's the case. I don't have time to check. Put it on a list
of things you'd expect Apache to do but doesn't yet.

Just had a nasty experience with the server at Cardiff. The error log was
filling with a permission denied responses (bogus) from one site in
Belgium. The error log grew to 150Mb and took out the server due to
lack of disk space for other requests. I shut it down for 10 seconds and
restarted and the problem disappeared.

Either Apache stuck itselef in an infinte loop, or the Belgian client
wouldn't take no for an answer. The "requests" were logged so rapidly that
I'd err on the side of an Apache infinite loop. Either way it was
a disasterous failure.


rob

Rob wrote:
>What I think apache should be doing is..
>
> if a "Location:" header is seen (alone or with other headers), and the
>destination starts with a "/", then do a local redirect to it... nothing
>more elaborate than that.

I think your recollection is wrong. What I wrote in my CGI specification
(based on NCSA 1.3 and Apache 0.6) was:

Location
This is used to specify to the server that the script is returning a
reference to a document rather than an actual document.
...
The location value is either an absolute URI with optional fragment, as
defined in RFC 1630 [1], or an absolute path and optional query-string. If
an absolute URI is returned by the script, then the server will generate a
redirect HTTP response message ... If the Location value is a path, then
the server will generate the response that it would have produced in
response to a request containing the URI

protocol "://" SERVER_NAME ":" SERVER_PORT rel-URL-abs-path

Status
The Status header is used to indicate to the server what status code it
should use in the response message. It should not be sent if the script
returns a Location header.

>The reason this is now an issue is that a user tried to do a local
>redirect from an asis file, but couldn't.

Did internal redirects from an asis file ever work? (It doesn't now.)

David.