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

[brian j. pardy]

On Tue, 8 Dec 1998, Klaus Weide wrote:

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

That's how it seemed to me as well.  I think that with persistent cookies
being used now, more people may be using cookies and finding some old bugs.

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

I think that with the added methods now to specify specific behavior for
entire domains (COOKIE_ACCEPT_DOMAINS), that even with the overhead 
involved, all cookies should be stored within a domain_list now.  The
ALWAYS_ACCEPT and ALWAYS_REJECT can be specified from .lynxrc, so behavior
isn't coming solely from interactive prompts now.

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

The impression I had looking over this was that it used to do something,
but it was redundant now.  

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

From just glancing at it previously during other changes, I did have the
feeling it was doing something interesting.  I never paid enough attention
to it, though I did wonder at first why d_o_i was handled differently, then
saw the lack of domain_entry.

-- 
GPG & PGP public keys: <URL:http://www.psnw.com/~posterkid/keys/> 
PGP fingerprint: 42 57 B3 D2 39 8E 74 C3  5E 4D AC 43 25 D2 26 D4