W3C home > Mailing lists > Public > www-talk@w3.org > July to August 1995

Re: Non-persistent Cookie proposal

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
Message-Id: <Pine.SOL.3.91.950811154224.5767G-100000@eat.organic.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:18 GMT