lynx-dev persistent cookies (was: Post-query bug)

[Klaus Weide]

On Sun, 6 Dec 1998, brian j. pardy wrote:
> On Sun, Nov 29, 1998, Elwin Oost wrote:
> > Hi,
> > 
> > I think I found a bug in the Cookies section when one dumps the 
> > output immediately with a post query.
> > 
> > I want to fetch a post_data page from a site which redirects with a 
> > 302 (indeed, Microsoft) and keeps track of the user with a cookie. 
> > This didn't work, I checked all the switches and then dug into the 
> > Lynx code to see whether I had missed one, and then (probably) 
> > found the bug:
> > 
> > LYCookie's store_cookie calls HTAlert's HTConfirmCookie for 
> > permission to store it. However, one of HTConfirmCookie's 
> > requirements is that the domain entry de isn't empty. However, with 
> > dump_output_immediately it stays NULL.
> 
> Could you try this patch out?  It's against 2.8.2dev.8, and looks to me
> like it fixes a problem, but it may not be yours.  I didn't see anything
> specifically related to post_data, but only to dump_output_immediately.
> 
> You were right about the domain entry de not being initialized in dump
> immediately mode, I got rid of that.  With this patch, there are no 
> special cases in LYCookie.c when we're in dump_output_immediately mode. 
> [...]

I haven't tried the new code, but it looks ok to me as far as I have looked.

I think it would be less confusing if store_cookies did not call
HTConFirmCookies at all for de->bv == FROM_FILE, since no confirmation
is ever involved - it will always return TRUE.

Or, which would be much better, HTConfirmCookies should not return TRUE
automatically for all FROM_FILE cookies!  I think this needs to be
resolved:
            /*
             * Ok, this is a problem.  The first cookie for a domain
             * effectively sets the policy for that whole domain - for
             * something like Netlink, where there are lots of websites
             * under www.netlink.co.uk, this isn't sensible.  However,
             * taking this sort of decision down to cookie level also
             * isn't sensible.  Perhaps something based on the domain
             * and the path in conjunction makes more sense?  - RP
             */
It is not obvious to me why taking this to the cookie level is not
sensible.

Currently Lynx is misleading the user if (s)he uses persistent cookies but
still wants control over accepting cookies.  The Cookie Jar page says
(Persistent Cookies.) for any domain with a cookie read from the persistent
file and gives no indication that this actually means (All new cookies
automatically accepted and you will never be prompted.)!  The documentation
also doesn't tell this part of the story.  According to the text in the
Users Guide, Set-Cookie MIME headers should still invoke confirmation
prompts.


   Klaus