On Thu, 27 Sep 2001, Roth, Kevin P. wrote:

> >- If the cookies are read from a file with stored headers, curl will
> > treat those cookies internally as "matching any domain".
>
> I'm assuming this choice is because the stored headers don't contain the
> host name? This seems reasonable.

Yes that's exactly why. libcurl will then assume that you pass cookies that
you think are valid for this session.

> >- When writing domain-less cookies to a cookiejar file, libcurl now
> > stores them with the domain 'unknown' which effectively will prevent them
> > from being used in any subsequent requests. If you have suggestions on
> > other treatments, please speak up.
>
> I don't like this. Is there any particular why you wouldn't simply record
> the host-name as the cookie's domain (instead of 'unknown') when writing
> to a cookie-jar file? I would assume this is how netscape does things...
> It appears that MSIE 5 makes this assumption (if domain isn't specified
> it belongs to the hostname) and that MSIE actually records the "assumed
> domain" as part of its cookie-jar file.
>
> Or, did you mean to say that the 'unknown' is going to be applied when
> writing cookies to a cookie-jar that were read from a stored-headers
> file? In this case, it makes sense to do what you've done above.

Your latter assumption is what I was referring to: when curl reads cookies
from a header file where the cookies have no defined domain and those cookies
are later written to a cookiejar file.

> It may also make sense to simply NOT write the cookie into the cookie-jar
> (if it won't be usable again, why bother?)

That might be an option, yes. But I'd rather store the cookies fine by
default so that they'll get noticed by users, and then we could think of some
kind of filtering function so that a user or an application can tell libcurl
what to save and not save in the jar.

And all this needs to get documented of course...

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/