httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Wilson <>
Subject Re: redirection revisited
Date Tue, 04 Apr 1995 09:36:37 GMT

> Also, while I was doing this I fixed,

[the man doesn't sleep?]

>  1) a die() redirect after an AUTH REQ will always return a 401 status,
>      so you can have a beautiful html file to explain how to register,
>      'cos it'll come back with a 401 instead of a 200 status.

Mmm, is there any way that we can have a different .html file depending on
the accessing URL?  The way I see it different 'applications' on the server
would have different test they wished to display to the user.  Suppose Joe-Average
was issuing a passwd to a mail-order form, well, they might prefer to see
an explaination from "Bumpy's Friendly Mail-order" rather than from
Webmaster@Oh.Rilly.Corp.  Perhaps there's scope for yet another obfuscation of the
.htaccess file which allows *users* to define the page to be used in the event of
an error:

--- cut here ---
[... usual .htaccess stuff ...]
ErrorPage 500 bumpys_error_report_form.html
ErrorPage 401 bumpys_howto_register_FAQ.html
--- cut here ---

So any error 401 reached in the same directory as the .htaccess file can result
in Bumpy's FAQ rather than the admin's FAQ-of-last-resort.

>  2) all redirects, whether explicit or after a die() will log both
>      the original URL and the new one,
>      e.g.
> - - [03/A .. ] "GET /cgi-bin/loc?weeeeeee HTTP/1.0" 302 0
> - - [03/A .. ] "GET /cgi-bin/tester" 200 1506
> {/cgi-bin/loc redirects to /cgi-bin/tester}
> and
> - - [03/A .. ] "GET /cgi-bin/crach?bleah HTTP/1.0" 500 0
> - - [03/A .. ] "GET /try.html" 200 1148
> {/cgi-bin/crach?bleah is a buggy script, with ErrorDocument 500 pointing to
> /try.html}

Cool, BUT I'M NOT SATISFIED YET! ;)  Is there any indication that the initial
access resulted in the redirect, other than entries being next to each other and
having the same date?  Time stamp resolution isn't enough to determine precisely
which initial access is responsible for a cascade of redirects [if we even allow

I'm a real-life OO-fascist, the sort of guy that likes to see unique identifiers
associated with all transactions.  Can we have some kind of transaction identifier,
a unique value chosen at the initial access time, which can be used to tag all
log entries resulting from an access.  This could be a CGI variable too
SERVER_TRANSACTION (or whatever), so that scripts can get a grip on things, perhaps.

So, if the server's logging transactions, and we've enabled the log-file to record
things we might see: - - [03/A .. ] "GET /cgi-bin/loc?weeeeeee HTTP/1.0" 302 0 46393272 - - [03/A .. ] "GET /cgi-bin/tester" 200 1506 46393272 - - [03/A .. ] "GET /" 200 2425 28372104 - - [03/A .. ] "GET /cgi-bin/crach?bleah HTTP/1.0" 500 0 38626102 - - [03/A .. ] "GET /try.html" 200 1148 38626102

Now we're *really* sure which access caused which redirect.

Well, that's one way of doing it.

> You don't deserve it, but I also introduced a new variable "REDIRECT_STATUS"
> which will let scripts now why the redirect happened. e.g. if it is
> set to 500, then we know that REDIRECT_URL exploded on us. So you can
> now write a general purpose problem reporter/analyzer.


> A cleaned up patch will be uploaded to hyperreal tomorrow, assuming
> nobody has a problem with the above.
> robh

I went to the same school as this guy you know. ;)


View raw message