- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Mon, 26 Aug 96 14:44:59 MDT
- To: Koen Holtman <koen@win.tue.nl>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>If people are confused by this, then maybe we need to add some
>clarifying language that makes it explict: a proxy SHOULD NOT
>(or perhaps MUST NOT) retry a request that completed with
>a successful transmission of a response, whether or not that
>response is acceptable to the requesting client.
Clarifying language like this is already in the draft, see the end of
Section 13.1.1.
Right, I had forgotten about that.
The start of 13.1.2 could be interpreted to
contradict the clarification as far as the Warning header is
concerned, though.
I believe that the start of 13.1.2 does not contradict the no-retry
policy, but maybe that's not the part you are talking about anymore.
It says that a cache must (probably should be "MUST") return a
Warning if the response is neither first-hand nor "fresh enough",
and the end of section 13.1.1 says (in essence) "don't add a warning
if the response is being forwarded but is not fresh enough."
I.e., the Warning should be added if the response is
(1) taken from the cache
and
(2) is stale
and should not be added otherwise.
Perhaps this part needs a little rewording to make this rule explicit.
My concerns are mainly about cache implementers
who just get it wrong, and add a Warning:stale when they should not.
Like I said, `obvious' mechanisms added for robustness could easily
cause catastrophic failure when deployed in a chain of proxies.
This danger seems rather speculative. I'd suggest deploying the
spec, as written, with the understanding that it is easier to relax
this kind of rule in a latter draft (after some operation experience)
than it would be to start out loose and later make it stricter.
-Jeff
Received on Monday, 26 August 1996 14:55:00 UTC