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/