Re: Should server beable to say NoCookie, No Show?

On Tue, 25 Mar 1997, Koen Holtman wrote:

> David W. Morris:
> [...]
> >Symetry would suggest that since we encourage/allow a UA to discard a
> >cookie under the user's discretion, we should have an optional attribute
> >which allows the server to stipulate one of the following:
> >
> >  a.  Dont show the page if the user rejects the cookie
> >  b.  Warn the user that if the cookie isn't accepted, the application
> [...]
> 
> Servers can already do this under the existing spec.  It is relatively easy
> to build a `cookie-enabledness' detector by using redirection.
> 
> So I see no need to burden the protocol with yet another extension: this can
> be solved with some clever CGI scripting.

No, all such a script can be sure of is prior behavior of the user or UA, 
not what the user/UA will do with the current cookie. 

Robust interoperability should be the design principle and requiring
clever CGI scripting to converge on robustness makes it very difficult for
application developers.

So what we have is the scenario:

1.  User goes to a page and rejects the cookie
2.  User fills in the form on the page and submits it
3.  The server comes back and says ... you must have rejected a cookie,
    I can't accept your request, but if you accept the cookie on this
    page, you can continue.
4.  User didn't get to read the page before rejecting the cookie again
5.  Now the user sees the page and has to decide how to recover.

The net result is that users will mostly blindly accept cookies because
they fear the difficulty of recovering when they don't. All the effort
spent on privacy by the WG will be moot.

Dave Morris

Received on Tuesday, 25 March 1997 14:33:02 UTC