Re: Location, URI-header, etc.

Shel kaphan writes on reliability problem caused by Location in 2xx
responses:
> 2. Reliability.  The reliability problem that would be introduced by
> Location in 2xx headers would be different from the the current
> situation in degree, not in kind.  It is already possible to get
> anomolous, though technically "correct", behavior from caches that go
> offline sometimes (described previously).  The same sort of problem
> would be introduced if caches ignored or didn't recognize Location
> headers and failed to invalidate other items as a result -- the cache
> could occasionally serve up older, though not expired, documents.
> Proper use of GET-IMS would vitiate this, as clients with newer
> versions, when re-requesting a resource through a cache with an older
> version, would force a newer version to be loaded.  All in, though,
> one cannot deny the existence of a robustness problem, especially
> during the period of time where many non-conforming caches exist.
> However, HTTP version numbering would help this.
The situation is worse. Let (clients of) caches A and B access the
same server, and one client of A get a response saying: cached copy
of 'URI X' to be invalidated (using Location). Cache A may use this
information to invalidate the cache as needed, but Cache B may have
a cached copy, and will not hear the news on 'cached copy of URI X
no longer valid'. And clients of cache B will receive stale version
of URI X.  

<em>
For now, better to restrict applicability of '2xx Location' to
'Expires: <yesterday>' URIs, and in next version of the protocol
(maybe 1.2?) elaborate the full mechanism of the event driven
expiration.
</em>

In fact, all human made Expires headers will be rough estimates, and most
implementations will check documents before their expiration. Picky
implementations will check practically every time. Others
will re-check less often before expiry date and more often after.
But unfortunately at least some implementations (likely to netscapes
'recheck once per session' option) will have options to configure
themselves to 'tuned' behaviour. (By supressing some portion of checks
ordered by the spec.) (Under check I mean conditional GET of course.)
I estimate this according to Murphy's law.
Or am I too pessimistic?

Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>

Received on Friday, 1 September 1995 14:45:19 UTC