- From: Brian Behlendorf <brian@organic.com>
- Date: Fri, 11 Aug 1995 16:00:35 -0700 (PDT)
- To: Roy Fielding <fielding@beach.w3.org>
- Cc: www-talk@www10.w3.org
On Fri, 11 Aug 1995, Roy Fielding wrote: > For example, the Cookie mechanism indiscriminantly defeats caching > by changing the request profile in an opaque fashion. Cache managers > cannot determine how it has been changed, or why, or even if the > response is cachable in spite of the cookie. The result is that the > cookie-based transaction will be cached because it is too expensive > not to cache it. > > In contrast, the same functionality can be achieved without defeating > caching by separating the 1% of stateful information from the 99% of > cacheable information, thus removing the need for cache managers to > ignore server desires. It is no harder to implement this than it is > to implement cookies, and the result is a far more reliable service. It is harder to implement for the server-side application developer, but if the drawback of not doing so is having your site cut off from access by conservative cache administrators, then some sites might be sufficiently compelled to do this. With this in mind - it seems that if we simply establish the rule that cookies/state headers are defined to *not* be a part of the key in a cache, that pages with cookies *can* be cached, and that the other *currently-existing* mechanisms for cache consistancy control are enforced (Expires, etc) then it's up to the server-side application developers to do this properly. This unfortunately requires properly configured caches, which are few. Conformance suites, anyone? With the onus on the server-side application developers to do this right, the cache administrators still have the right to deny access to servers which give them grief. It seems an advanced cache anlysis tool could aid in this process - one that identifies those sites which have the greatest amount of uncacheable information and highlights that to the site administrator. What would HotWired do if suddenly AOL told them they would refuse all requests, hmm? :) Still got about 50 messages on this topic to read, so I may be off-base here. I've given up on the concept of a simple ID header, and if we can remove the cache-killing aspects of the cookies/state-info proposals, I don't have a problem with it. One thing that would encourage the use of Expires: headers of course would be a way for caches to report hits they served directly without a long-distance conditional GET. The only reason it's not done a whole lot now is because hit counts are oh so precious. Brian --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-- brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Received on Friday, 11 August 1995 19:01:51 UTC