Re: lynx-dev more help trying to get lynx 2.8.2dev17 to eat all cookies

[Klaus Weide]

On Sat, 27 Feb 1999, brian j pardy wrote:
> On Sun, Feb 28, 1999, Larry W. Virden wrote:
> > From: brian j pardy <address@hidden>
> > 
> > > Those aren't pattern matching options -- you'll have to put
> > > www.remarq.com or .remarq.com or remarq.com, whichever the cookie is
> > > coming from.  Perhaps making them a regex would be nice, if someone
> > > feels creative.
> > 
> > Doggone - just when I think I have figured out which configuration parm
> > means what, I discover how wrong I am.
> 
> Perhaps we can do something about that -- I agree that some kind of
> pattern matching there, even if it's just a '*', would be useful.

The '*' (as I thought of it) would change the global default, that is
only very loosely like pattern matching.

The kind of matching that Larry expected - where .com would match all
domains under .com - doesn't really fit into the model.  The model,
as I see it, is that these lists set properties for specific
"cookie domains" - which are unambiguous objects, not patterns for a group
of hosts.  The cookie domains are the strings that are received (or
assumed by default) in the Set-Cookie header (after some tweaking by lynx,
prepending '.'), and are exactly what appears as Domain on the Cookie Jar
page.

In his model, .com stands for a domain=.com received in a Set-Cookie.
But such a cookie domain can never be valid (even with loose checking).
Similarly, .c.com stands for cookies that would (if accepted) appear on
the Cookie Jar page with "Domain=.c.com".  I think changing the model to
interpret .com _in some contexts_ as a wildcard, for example for all
<something>.com hosts or for all <something>.com cookie domains, would
only increase confusion.

Of course, a domain .c.com *does* effectively mean something like "a
wildcard for <something>.c.com hosts" - when it is actually used by the
Cookie protocol implementation.  But that kind of matching should be
regarded as separate.  If we wanted to use it for interpreting the
cookie_* lists, we'd have something like a chicken-and-egg problem:
whether a.b.c.com matches .c.com in this sense depends on the outcome of
parsing the cookie_*_invalid_domains lists!

I think it is a question of the right comments in lynx.cfg etc. to make
clear what those "domains" are.   As well as to explain how the various
options work together.  Yes, you asked for comments on the lynx.cfg changes
a while ago, sorry I haven't worked on it yet.

    Klaus