httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <ako...@organic.com>
Subject Re: inneresting behavior
Date Tue, 18 Jun 1996 17:47:42 GMT
On Tue, 18 Jun 1996, Robert S. Thau wrote:

>   The following (untested) patch should do the trick:
> 
> Ummm... I'm afraid I'm getting the shivering willies over introducing
> this first in the release after 1.1b4 (1.1 final?).  If there's
> something broken about the way it behaves, then given the persistence
> of our final releases, clients and caches will be dealing with the
> brokenness will persist a fairly long time.

I agree. Go back and read my message; I don't want it in 1.1.0 either, I
suggested it for afterwards. But Rob asked how easy it was, and I just
wanted to point it out...

> The sort of thing I'm worried about is cases like this: suppose one
> CGI script indirects (via internal redirect) to another, which
> indirects to an actual file.  Then the first internal redirect causes
> Content-Location to get set to the URI of the second CGI script, and
> (the way this code works), the second doesn't cause it to be reset to
> the location of the actual file (since it *was* already set).  So, the
> request does return Content-Location, but it's at least arguably
> bogus.  Likewise, I'm not sure I understand yet all the potential
> interactions with ErrorDocument.

Not true, at any rate. Note that it checks for Content-Location in
err_headers_out (so a CGI script can set it permantely), but only sets it
in headers_out. This means that if you redirect several times, only the
most recent one will carry over, since headers_out do not preserve through
internal redirects. At least, that's my understanding.

> FWIW, my preference on how to implement this would be to have the
> Content-Location header set by whatever is actually serving up the content,
> since it is most likely to know what sort of Content-Location header, if
> any, is appropriate.  (This would also handle negotiated content, which
> doesn't always go through internal redirects at all).

Well, negotation is still up for grabs. I don't think "they"'ve decided
yet if content neg will use Content-Location at all, or for what purpose,
so I think it's actually best if we don't set it automatically for
content-neg'd stuff, until there's a spec.

At any rate, internal_redirect is called almost every time Apache serves
up a document that's located somewhere else, that could be a source for
relative link-related problems.

But I defenitely agree that it's something for 1.2, not 1.1.

-- Alexei Kosut <akosut@organic.com> 
   http://www.nueva.pvt.k12.ca.us/~akosut/


Mime
View raw message