W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 1998

Re: Comments on draft-ietf-http-v11-spec-rev-03

From: Dave Kristol <dmk@bell-labs.com>
Date: Fri, 27 Mar 1998 17:25:32 -0500
Message-Id: <351C275C.1C70@bell-labs.com>
To: Koen Holtman <koen@win.tue.nl>
Cc: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5522
Koen Holtman wrote:

> - Section 13.10:
> This section introduces a new (as far as I can see) requirement:
> #  A cache that passes through requests for methods it does not understand
> #  should invalidate any entities referred to by the Request-URI.
> This may seem like a good safety measure on the surface but I think
> that it is in fact quite damaging.  First, designers of new methods
> cannot benefit much from the above rule because 1.0 and 2068 caches
> will not adhere to it.  On the other hand, the new rule introduces a
> performance penalty for new methods which do not in fact cause any
> invalidation.  One such method would be M-GET, a GET extended with a
> mandatory extension, for example.  The performance penalty blocks
> implied by the new rule makes certain ways of extending the protocol
> too expensive and thus shortens the lifetime of the 1.x suite.  I want
> the requirement to be removed.

I think I'm the instigator of this change.  While your example seems
benign enough, the danger is from methods that change the underlying
object, e.g., M-PUT.  The object in the cache would no longer look like
the one at the origin server and must be invalidated.  In the absence of
a way to tell intervening caches to invalidate their view of the object
the proxy cache has to do so by default.

I suppose a compromise would be for a cache to mark a cached object as
"must-revalidate" when it sees an unknown method that it passes along. 
Cache experts:  would that work?

Dave Kristol
Received on Friday, 27 March 1998 14:28:21 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:04 UTC