Re: lynx-dev http://www.slcc.edu/lynx/html/todo-list.html

[Klaus Weide]

On Sat, 17 Apr 1999, News Subsystem wrote:

> I'm not sure if the tod-list is being actively maintained...

Not very actively...

> but the stuff
> on there about Cookies seems too cookie-friendly...

Most of what's listed there seems to be in the current cookie code
(2.8.1, and more so 2.8.2dev.N).  Not just changes to make it
more "cookie-friendly" (less discerning in what is acceptable),
but also in the opposite direction.  (It's not all well documented,
things are still in flux.)  Quoting from that URL:

     * (Suggested by Hiram W. Lester, Jr.) Something needs to be done so
       that cookies can be accepted from all domains by default. This is
       available as command line "-cookies"; also see the cfg file

There is now -accept_all_cookies and ACCEPT_ALL_COOKIES.  Note that
the -cookies flag does NOT do this, the second sentence is wrong.
(-cookies is an overall flag to turn accepting of cookies on or
completely off.)

     * (Suggested by Hiram W. Lester, Jr.) Status message for accepting
       cookies even if there was an option to always allow all cookies.

In general, cookies that are deemed acceptable without needing user
confirmation are accepted quietly - a status message of each cookie
would be just too annoying, especially if the user had already said
he wanted such cookies.  But there *is* a message (duration MESSAGESECS)
   'A'lways allowing from domain 'XXX.XX.XX'.
the first time a cookie from a given domain is auto-accepted, *if*
this happens just because of -accept_all_cookies or ACCEPT_ALL_COOKIES
(as opposed to previous 'A'lways answer to a prompt, or presence of
the domain in a COOKIE_ACCEPT_DOMAINS list or in a persistent cookie
file).

     * (Suggested by Rolf Puchtinger) Would it be possible to prompt
       users for the option to save COOKIES with expiry dates longer than
       "session" in a permanent file in the user's directory for
       subsequent sessions?

Persistent cookies are implemented (but still marked "experimental").
Cookies with a given expiration in the future are saved to the persistent
cookie file on exit, if enabled.  This was broken in 2.8.1 though, it
even saves cookies that should not be saved.  (But they would be
discarded when the file is read the next time.)

> how about a feature
> that can be set to cache-and-erase all cookies,a la Junkbuster?

How would that work?  Not sure what chaching means in this context.

The current cookies control options all affect the 'receiving' side of
the communication (whether to accept a "Set-Cookie:").  I have been
thinking of YA setting to suspend/resume the *sending* of cookies
independently (whether to send "Cookie:").  Maybe that's similar to
what you mean.

It's not strictly needed to have an option to control sending
independently; if lynx never 'accepts' cookies (from either a server
or a cookie file), it won't have anything to send.  But toggling
cookie sending on and off would be nice touch (mostly for testing
whether cookies make a difference and are needed for a given service,
probably).

> Or a
> pernmanent list of domains for each user to really "neVer accept" rather
> than having to enter the V command every session?

There is COOKIE_REJECT_DOMAINS now.

   Klaus