W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1995

Re: Proposal: Pragma min-age (Was:Re: A modest proposal)

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Fri, 18 Aug 95 18:44:55 MDT
Message-Id: <9508190144.AA10426@acetes.pa.dec.com>
To: Roy Fielding <fielding@beach.w3.org>
Cc: Koen Holtman <koen@win.tue.nl>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Koen writes:
    >Such a `tuned' cache would introduce incorrectness
Roy writes:
    No, it *might* introduce incorrectness.  I claim that over 99% of
    today's non-cacheable pages are still "correct" after being cached,
    where correctness is defined as containing the same substantive and
    qualitative information content as would be obtained directly from
    the origin.  [Note: my claim is based on personal observation, not
    controlled experimentation]

I hate to be pedantic, but let's try to maintain a distinction
between a "correct protocol" and "correct results".

A correct protocol is one that never yields incorrect results.
(Usually, this is respect to a given failure model; that is,
you have to say what kinds of failures you are willing to defend
against.  But that's splitting hairs.)

A correct result is one that would have resulted from a correct
protocol.  An incorrect protocol can generate correct results,
but doesn't always do so.

Roy's claim about "99% of today's non-cacheable pages" is one
about correct results.  Koen's statement is about an incorrect
protocol (or rather, an incorrect implementation of the protocol).

I agree with Koen that some proxy implementors (or managers) may want
to violate the protocol spec, for reasons of their own.  But this
is outside the realm of the HTTP spec, and I agree with Roy that
the spec should not be twisted to support it.

On the other hand, there is some merit in in allowing a cache
to return an object of questionable validity.  For example, suppose
the original server is down; should the cache return "sorry" or
should it return a possibly invalid object?  Or (to be more
speculative about future versions of HTTP) if the server is really
slow, perhaps the cache could return the possibly invalid version
quickly, and then update it with the proper version when it arrives.

Or perhaps the cache is "tuned" as Koen has described.  (I might say
"kludged" instead of "tuned" :-).)

I suggest that these are potentially useful things for a cache to
do, but we ought to think about protecting the ultimate user against
the possible inconsistency.  Koen suggested a Pragma sent as part
of the request, implying that the user agent controls how the cache
handles inconsistency, but this doesn't actually help the user
decide if the response is questionable or not.

How about doing things the other way?  Any cache (including
one inside the user agent) that returns a possibly invalid
object must mark it with (of course) a new header:
	Possibly-invalid : <reason-why-string>
The reason-why-string would be some sort of explanation of what
is suspect.  For example, "server is down, this is 1 hour old"
or "we are ignoring Expiration dates from this server, but if
you care, the file expired in 1991", or "server is slow, try again soon
but meanwhile here's my 2-hour-old copy".  Actually, the latter
might better be handled by a different kind of response, to allow
a browser to automatically update the page when it arrives from
the server.  Maybe:
	Possibly-invalid-try-again-soon : <reason-why-string>
In HTTP 2.0, the cache could probably simply promise to send
the response along as soon as it arrives.

A browser could use some sort of status line, or pop-up window,
or whatever, to display this warning to the user.  Cascaded proxies
would have to convey the warning, but of course they would naturally
do that with an unexpected header.

This approach allows the cache to do almost anything, but ensures
that the user is never mislead about the validity of a page.

A user who doesn't like the idea of looking at an invalid page
can always hit "Reload".

Received on Friday, 18 August 1995 18:47:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:14 UTC