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

13.1.1 Cache Correctness

From: <jg@w3.org>
Date: Thu, 06 Jun 96 07:43:59 -0400
Message-Id: <9606061143.AA00917@zorch.w3.org>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/818
Koen discovered a possibility that the spec did not cover, where
a response might become stale in transit.

The wording below will appear in draft 05 (presuming there is one)
to clarify the problem.  Let me know if there are any problems with
				- Jim

------- Forwarded Message

From:  koen@win.tue.nl (Koen Holtman)
Message-Id:  <199606060743.JAA23497@wsooti06.win.tue.nl>
Subject:  Re: Seems like a plausible reason... What's your current opinion?
To:  mogul@pa.dec.com (Jeffrey Mogul)
Date:  Thu, 6 Jun 1996 09:43:37 +0200 (MET DST)
Cc:  koen@win.tue.nl, jg@w3.org, mogul@pa.dec.com
In-Reply-To:  <9606052252.AA15815@acetes.pa.dec.com> from "Jeffrey Mogul" at Jun 5
, 96 03:52:02 pm

Jim, can you comment on if you want to add Jeff's language below to
the spec?

Note to Jeff: e-mail etiquette forbids me from forwarding this to the
main list, though it should be forwarded soon.  If you want to forward
it, that is OK with me.

Jeffrey Mogul:
>    Suppose we have an arrangement
>      ORGS --- C1  -- C2 --- C3 --- UAG
>    were C1 -- C2 is a satellite link with an approximate 4 second rtt.
>    If C3 does a request through C2, a possible response is:
>      HTTP/1.1 200 OK
>      cache-control: max-age=2
>      Age: 4
>    C3 won't know if the response came fist-hand from ORGS or with an age of
>    1 out of C1's cache memory.
>    It seems a very bad idea for C3 to try to revalidate the response, I
>    think you risk an infinite loop, but I'm not exactly sure.  In any
>    case, C3 will, in the absence of a means to detect first-handness,
>    have no choice but to add a warning to the response, which also seems
>    like a very bad idea because of the cry wolf effect.
>You're right that the protocol spec should not encourage an infinite
>loop.  However, I think we can do this by adding the following
>clarification to section 13.1.1 (Cache Correctness):
>	If a cache receives a response (either an entire response, or a
>	304 [Not Modified] response) that it would normally forward to
>	the requesting client, and the received response is no longer
>	fresh, the cache SHOULD forward it to the requesting client
>	without adding a new Warning (but without removing any existing
>	Warning headers).  A cache SHOULD NOT attempt to revalidate a
>	response simply because that response became stale in transit;
>	this might lead to an infinite loop.  An end-user client that
>	receives a stale response without a Warning MAY display a
>	warning indication to the user.

I think this solves my `cry wolf' problem, and the additional warning
about infinite loops is also good to have.  I think these words are
important enough to warrant adding them to the spec at this late a




------- End of Forwarded Message
Received on Thursday, 6 June 1996 04:46:09 UTC

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