httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Re: inneresting behavior
Date Tue, 18 Jun 1996 17:42:21 GMT
  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.

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.

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).

rst

Mime
View raw message