Re: Non-persistent Cookie proposal

Dave,

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
below.

Dave Kristol:
>koen@win.tue.nl (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
meta-information.

[...]
>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
providers.

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
option.

>Dave Kristol

Koen.

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