httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Hartill <>
Subject Re: WWW Form Bug Report: "can't retrieve real document if error doc is newer" on BSDI (fwd)
Date Fri, 22 Sep 1995 21:22:34 GMT
Roy said..

> And if you shoot yourself in the leg, it's quite possible that pain
> will be the result.  So?  Don't shoot yourself in the leg.
> When Apache implements an internally random redirect, then the random
> redirect gets no-cache set.

but that's not what I'm seeing when I use the thing. Apache redirects
and the IMS is being used on the url I'm redirecting to, and the response
of the redirect doesn't say no-cache or anything else that would give
the client a clue that this is not the same internal URL as before.

>  The same is true of scripts -- if they
> want no-cache, they can bloody well ask for it.

scripts can bloody well do what they want, but if the url you
redirect to isn't a script it can't account for the problem, so
the client is bloody well screwed.

If a script does an internal redirect, Apache discards that script's
headers, or at least I can't get "Pragma: no-cache" to be added.

> >My point is that if you start redirecting, the IMS value given by the
> >client should be discarded, because there is a reasonable chance that
> >it will be used out of context.
> No there isn't.  There is a single point in time at which the server
> may, by some strange chance in which the old response is newer than
> the new response, that the cache in question will get a 304
> when it shouldn't.  So, that cache has an old copy (which was perfectly
> valid before) until that cache is flushed.  No big deal.

I'd say it's a big deal if the client is told there's "no change" 
even though there has been.

> >I think the safest approach is therefore to toss the IMS value at the
> >first redirect, that way Apache can't send a 304 under any circumstance.
> No.  If the server ignores IMS for resources in which it is capable
> of determining a Last-Modified date, then that server is broken.

Not broken, just inefficient.

The choice seems to be inefficient but accurate or efficient and potentially

> The safest approach is to simply take the maximum (latest) of the
> last-mod times of all the redirects and use that for the comparison.

I assume you mean a script does this. But script headers which
accompany a redirect go to /dev/null AFAIK.

> >> In any case, caches are not allowed to cache error responses, and IMS
> >> should be checked only if the response would otherwise be 200.
> >
> >the problem is more general than just ErrorDocument and gets worse
> >when you also hit a Netscape caching bug.. if you request a URL that
> >first produces HTML, then later produces, say postscript, Netscape seems
> >to keep the HTML cached with the postscript's last-modified date, so
> >subsequent reloads keep giving you the HTML. Discarding the IMS
> >because of the redirect should solve this.
> What, replace a once-in-a-billion bug with a once-in-a-thousand bug?
> No thanks.

I must be very unlucky then, 'cos I've seen both in real applications.

Write a script that redirects to something recent, hit the URL for the
script, now change the script to redirect to something older. If you give
Apache the IMS, you'll always see the newest object.

Now if the script was able to redirect to different objects by iteself
(which many scripts already do .. I have examples) the problem has a
much greater than one-in-a-thousand chance of showing itself.

The problem with if-modified-since in an internal redirect situation
is that Apache makes no effort to check *what* has supposed to have been
modified. What seems to be happening is that Apache compares the age
of the object to be sent with the IMS, even though that object can be
often be different.

Now if only clients could say "if-foo-modified-since" where foo maps to
something unique, there'd be no problem. It's too late in the day for me
to guess what "foo" needs to be.


View raw message