Re: Non-persistent Cookie proposal


Thank you for your comments.  To save bandwidth, I will not reply to
all of your comments below, but I will keep them all in mind when
writing a future version of my proposal.

I have not been as clear about how my proposal solves broken cache
problems as I wanted to.  I have written some more clarifications

Dave Kristol:
> (Koen Holtman) wrote:
>  > Non-persistent Cookie proposal
>  > ==============================

>This is a great list!  Mind if I steal it for my proposal?

No, go right ahead.

>You failed to use the [4] terminology above and below.  In particular I
>think you mean "origin server" where you say "server" and "web server".

You are right.  Some of my terminology is inaccurate or confusing.  In
particular, I used `a browser is honoring a cookie request' to denote
a _state_ the browser is in, I should probably call this `a browser is
carrying a cookie' or somesuch.

I tried to avoid your `beginning/end of session' terminology: talking
about sessions is also confusing: one would expect there to be a
mechanism for an origin server to discover that a session has ended.

> > [terminology: cookies are never interpreted by the browser]
>Actually, Netscape's cookies are interpreted by the browser to the extent
>that it returns them selectively to the origin server, based on request
>URL.  It also makes them expire.  Those two points are different from my
>proposal, where the browser does not peek inside.

I read the netscape proposal to mean that the NAME=VALUE pair in their
Set-Cookie header is the actual cookie (that is never interpreted),
and that the other X=Y pairs in the header are cookie

>If you're referring to my State-Info (formerly Session-ID) proposal, this
>is a misunderstanding.

No, I was not referring to it.

>  > Non-persistent information: information that is lost when the browser
>  > exits
>Perhaps you need to add words about what happens when one window of a
>multi-window browser exits.

I should, but I have no idea what to do with state information in
multiwindow browsers.  Both sharing between windows and not sharing
have their disadvantages.  I should probably add a section about this
being a problem not solved by the proposal.

>  >                                      Sending Set-Cookie headers only
>  > to get better clicktrail statistics should be considered a breach of
>  > etiquette.  To get clicktrail statistics, the Request-id header (see
>So cookies are not for statistics!?
>  > the appendix below or [2]) should be used.

Yes, cookies are not for statistics.  My two proposals separate
clicktrail statistics provisions from stateful dialog provisions.


> [Objections to reasons 1) and 3) in section 5]

You are right, I should probably just delete reasons 1) and 3): 2) is
the only real reason for the proposed default behavior.

>  >     By making responses in stateful dialogs using the Cookie headers
>  >     a special case in the cache algorithm, independent of `Expires
>  >     tuning', this particular non-conformance risk to stateful dialogs
>  >     is eliminated.
>It seems to me it will take at least as long to deploy caching proxies
>that understand (and don't cache) requests/responses that use
>Cookie/Set-cookie as it will to fix badly tuned caching proxies.

I'm not primarily concerned about fixing broken (badly tuned) caches
that are broken _now_.

I'm concerned about a _future_ practice of cache administrators breaking
their non-broken caches on purpose.  

In his philosophical statement in this thread (posted on www-talk
only), Roy Fielding seems to say that breaking the cache might
actually be a honorable thing for a cache administrator to do, given
the fact that there are selfish sites that abuse Expires headers for
frivolous reasons like getting higher hitcounts.

I would not go as far as calling breaking a cache honorable, but it is
something that needs to be taken into account by stateful dialog

The way to deal with the breaking of the Expires semantics is to have
a second cache-disabling mechanism that will _not_ be abused
frivolously by selfish sites, so that cache administrators feel no
need to break caches for the second mechanism.

My `do not cache if Cookie header present' default is one such a
mechanism.  Frivolous abuse of this mechanism will be discouraged by
the fact that a large number of browsers will pop up a `honor this
set-cookie header?' dialog box when such a header is sent for the
first time.

>I thought a caching proxy was obliged never to cache a response to a
>request that carried a Cookie header (sect. 4).

No, the `do not cache if Cookie header present' _default_ behavior can
(and should, if appropriate) be overridden by the service author
putting an Expires header in a response.

>  >  1) the entity included may be cached, but not beyond the
>  >     <date> given,
>Before you didn't trust caching proxy operators to treat Expires
>correctly.  Now you do?

I don't trust the operators to treat Expires correctly in the _normal_
case, if _no_ Cookie header is present in the request.  The text above
talks about the (new) semantics of Expires in the unusual case, if a
Cookie header is present.

In your State-Info proposal, you must always trust cache operators.
The question is whether you can.

If stateful dialog providers (like tele-shopping sites) cannot trust
cache operators to disable caching of their stateful dialog responses,
they will have to implement `state-in-the-url' hacks or other such
schemes to prevent response caching.  These schemes will also have a
negative impact on the caching ability of non-broken caches that play
by the rules.

Tele-shopping sites cannot just ignore broken caches: risking a
lawsuit by a customer who was bitten by a broken cache is not an

>Dave Kristol


Received on Saturday, 12 August 1995 07:59:09 UTC