Re: Non-persistent Cookie proposal

Koen Holtman (
Sat, 12 Aug 1995 13:58:37 +0200 (MET DST)


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