[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Cookie problems?

From: brian j. pardy
Subject: Re: lynx-dev Cookie problems?
Date: Fri, 25 Sep 1998 15:54:28 -0700 (PDT)

On Fri, 25 Sep 1998, Bela Lubkin wrote:

> brian j. pardy wrote:
> > On Fri, 25 Sep 1998, Heikki Kantola wrote:
> > 
> > > I today compiled 2.8.1pre1 under digital UNIX without hassle, but I've
> > > run into few problems with cookies:
> > > - first persistant cookies support I chose to have doesn't appear to
> > > work as I don't see that Lynx would write anything to .lynx_cookies.
> > 
> > This is something that still needs to be fixed. Cookies (as of dev.28 or so,
> > and I believe are the same in pre1) are NOT written to .lynx_cookies unless 
> > you hit ^K to go to the cookie jar page.
> > 
> > It's easy enough to change this in the source, I'm not sure where we want 
> > to do it, though. Most likely at the beginning of the cleanup when exiting
> > lynx.
> > 
> > Any ideas/comments from Rob or anyone else?
> Yes: this could lead to various sorts of "surprising" behavior if Lynx
> exits unexpectedly(*).  The least surprising behavior would ensue if
> Lynx updated the persistent cookie file each time it received or used a
> cookie (I'm assuming it keeps a last-used time stamp, for the eventual
> use of the expiry mechanism that doesn't yet exist).

I suppose the worst possible thing that could happen to the cookie file if
Lynx exits unexpectedly would be to lose any persistent cookies accepted
that session, but any from the file previously should indeed remain.

> However, fixing it properly will be a bit complex, so I would agree that
> for 2.8.1 it should just be changed to update (if changed) on exit.
> Further work should be saved for 2.8.2 development.

I agree here.

> (*) Yeah, Lynx isn't supposed to "exit unexpectedly", but we still have
> to defend against it.  I keep a Lynx running for days at a time.  If the
> machine panics or has a hardware failure -- which does happen -- I don't
> want days' worth of session information to be lost.  I would imagine
> that such failures are much more common for people running Lynx on
> DOS/Windows boxes.
> The only reason I can think of *not* to do this would be a concern that
> it would cause too much disk activity.  I strongly doubt this concern;
> I'm just trying to anticipate possible objections.  As far as I know,
> the only times that Lynx's picture of the cookie jar changes are when it
> receives a cookie, sends one, or the user does something on the cookie
> jar page -- all of which are mediated by the user's interactive actions.
> Since it's limited by user interaction speed, I don't think it's likely
> the file would be written "too often".

Again, I agree. 

> Another complication: if Lynx is updating the cookie jar all the time,
> it needs some sort of locking to protect against itself.  I'll use Lynx
> in multiple windows, switching to a second one while the first is
> processing a request.  So if it's automatically updating the cookie jar
> there's a definite potential for conflicts.  This potential is lower
> with the current setup, where it only updates when the user goes to the
> cookie jar page -- an action that is unlikely to procede asynchronously
> on two terminals at once.  The potential remains, and should definitely
> be addressed at some point.  (Part of the locking protocol would be for
> Lynx to *pick up* newly recorded cookies written by another Lynx
> process... definitely complex.)

If the updating is moved to happen at quit time, that should be about as
safe as updating only upon going to the cookie page. I think it'll be 
acceptable for 2.8.1.

A locking protocol and method of sharing between processes will need to be

A possible way might be to use to save cookies within
a session (after reading them from COOKIE_FILE at startup), and reconciling
with COOKIE_FILE at quit time -- possibly with the addition of a -fix_cookies
option or helper script to reconcile in the case of a session that exited
abnormally and didn't get to clean up.

GPG & PGP public keys: <URL:> 
PGP fingerprint: 42 57 B3 D2 39 8E 74 C3  5E 4D AC 43 25 D2 26 D4

reply via email to

[Prev in Thread] Current Thread [Next in Thread]