lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev Cookie+PostQuery+Dump_Immediately bug :)


From: Klaus Weide
Subject: Re: lynx-dev Cookie+PostQuery+Dump_Immediately bug :)
Date: Tue, 8 Dec 1998 06:12:44 -0600 (CST)

On Fri, 20 Nov 1998, brian j. pardy wrote:
> I wrote:
> > Taking a look at the code you mentioned, it looks to me like you're right.
> > 
> > Does anyone know a reason for the current behavior? It definitely seems
> > wrong to me.
> > 
> > Will have a patch soon-ish to take care of this, unless someone has a
> > reason against it..
> 
> On second thought, maybe I won't. It looks like weird things are done with
> dump_output_immediately. If someone else wants to take a look at this too,
> it'd be a good thing. It's confusing me. :)

I took a look too (maybe too late now).  The comment in HTConfirmCookie
seems to indicate that cookies were supposed to work in 
dump_output_immediately mode (if enabled), but it looks (to me) like
they never did work.  A cookie_list was initialized in store_cookie(), but
it would never be linked to a domain_entry in the domain_list even if
the HTConfirmCookie would be able to return TRUE.  So domain_list
(although initialized) would always remain empty, and so LYCookie could
never have generated a Cookie: header.

It looks like the dump_output_immediately case in LYCookie.c was something
like a hook, not really implemented.  It seems to make sense in this
case to omit the domain_list in this case (since it stores the responses
to interactive prompts, which can never happen for
dump_output_immediately) and have only one global cookie_list.  But
this use of the one cookie_list isn't really there.  (I mean in the
cookie code before persistent cookies etc.)

The only effect of the rudimentary dump_output_immediately implementation
may have been generation of cookie-related trace messages in some cases.

Maybe in the very first stages of the cookie code it actually did
something for d_o_i.  But *IIRC* when I made some changes to
LYCookieJar_free (1997-05-06 according to old CHANGES file) to avoid a 
("permanent") memory leak for d_o_i, store_cookie was essentially the same
as until recently, i.e. not really doing anything.  (I copied the added
code in LYCookieJar_free from the !d_o_i code above it with appropriate
modifications. Therefore there is code for freeing cookies from the
cookie_list, although I didn't expect that list to ever be non-empty.
This may have added to the false impression that the cookie code actually 
did something interesting for d_o_i.) 

      Klaus
       

reply via email to

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