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

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

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Fri, 27 Mar 98 14:51:16 PST
Message-Id: <9803272251.AA03713@acetes.pa.dec.com>
To: http-wg@cuckoo.hpl.hp.com
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.

Dave Kristol wrote:
    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?
    
How does
	mark the cached object as "must-revalidate"
differ from
	invalidate the cached object

except that the former propagates the change to outbound caches?

I'm not sure that Koen would view this as a compromise :-)

Would it work?  Well, the concept of invalidation-based protocols
is in general not supported by HTTP.  My preference is to err on
the side of transparency rather than performance, although I agree with
Koen that the transparency in this case might be somewhat illusory.

But I'm not sure what the problem is; my understanding is that
the whole point of creating the M-GET method is to prevent
"proxies that do not understand the method" from forwarding it.
I.e., they are supposed to return 501 (Not Implemented) or act
as a tunnel (i.e., not cache anything).

So any caching proxy that does forward M-GET does "understand" it, and
isn't covered by the requirement that Koen objects to.

-Jeff
Received on Friday, 27 March 1998 14:53:59 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:14 EDT