lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev extended cookie control (was: more help trying to get lynx


From: brian j pardy
Subject: Re: lynx-dev extended cookie control (was: more help trying to get lynx 2.8.2dev17 to eat all cookies)
Date: Sat, 27 Feb 1999 21:53:57 -0800

On Sat, Feb 27, 1999, Klaus Weide wrote:
> On Sat, 27 Feb 1999, Larry W. Virden wrote:
> 
> > accept_all_cookies=TRUE
> > cookie_accept_domains=
> > cookie_reject_domains=
> > cookie_loose_invalid_domains=.com,.edu,.net
> > cookie_strict_invalid_domains=
> > cookie_query_invalid_domains=
> 
> Seeing these together reminds me -
> 
> What do you think (Brian, especially) about extending the syntax
> of those lists to allow "*"?  For example,
> 
>   cookie_loose_invalid_domains=.remarq.com
>   cookie_query_invalid_domains=*
> 
> would set the default behavior, for domains that are not otherwise
> listed, to "query".  accept_all_cookies=TRUE would be redundant
> (but could be kept for compatibility) for cookie_accept_domains=*
> [I think].

I think it would be nice, but...

> This wouldn't be trivial to implement in a meaningful way though,
> regarding precedence / order of processing.  Basically first all
> the "*" from all the options would have to be handled (in a to-be-
> determined order or precedence), then all the specific domains.
> It gets more complicate because there are two places where these
> can be set, lynx.cfg and .lynxrc.  It would make sense to first
> collect all the strings without setting anything yet, then when
> the strings from both potential sources are there determine the
> precedence (something like that seems to be already there, I admit
> I haven't looked closely).

It would certainly not not be trivial.  I think it would surprise the
user the least if wildcards worked, as Larry just showed.  

My time to hack on the code is about to diminish severely -- I'm about
to move across country, so things are going to be hectic.  This may be
the sort of thing that should be added earlier than this point in the
dev cycle, it seems there may be enough existing little buglets (as
this one that Larry just pointed out, I think it's in the code) that
adding too much more might not allow a reasonable debug time before
2.8.2 should be out.

I'm going to look into this path check thing, it looks like it's not
matching for the path check, somehow.  I didn't have any sites to test
the path check on, if people could stress-test this the way Larry is,
it definitely needs it.

-- 
So this it it.  We're going to die.

reply via email to

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