On Wed, 25 Jun 2003, Cris Bailiff wrote:

> just had a quick skim through the proposal - seems OK to me (I need to try
> coding to it to see if it really makes sense!)

Hehe, yeah me too! ;-)

> * I didn't really see what the 'provided' bits get you? What's the issue
> with just passing NULL/0 where data isn't supplied? This is effectively how
> the cookie comes from the server - the things not provided just aren't
> there.

Uhm... I must not have been thinking clearly when I added that. Removed again!
Thanks.

> * New cookie attributes aren't supported.
>
> Theoretically, the cookie string could have extra "name;" or "name=value;"
> tags appended in future.

Yes. Even the good old RFC2109 from 1997 includes cookie items that are never
used anywhere by anyone. libcurl in fact has support for some of them.

The reason I didn't add them to the struct is that I believe that they will
never be used. The cookie system once set by Netscape is probably "good
enough" for most people.

> Although currently non-standard, there is at least one extra cookie flag
> which is likely to become more common-place - 'httponly'.
>
> http://msdn.microsoft.com/workshop/author/dhtml/httponly_cookies.asp
>
> This is a new security-related flag supported by IE6 - despite being an MS
> 'invention', is does have some merit, and might make it into mozilla.

Funnily enough, this particular one won't make any difference to libcurl since
it already deals with HTTP-only cookies (as this option clearly means "don't
let scripts be able to access this cookie")! But I get your point.

> Boolean flags (at least) could be supported by making it 'long flags'
> instead of 'bool secure', and having some constants for SECURE and HTTPONLY,
> but I don't know at what point you'd need to worry about extra arg/value
> pairs...

Reading the more recent cookie RFCs (such as RFC2965), you'll see that there
are other options such as Port, Version, Comment and CommentURL that are
name/value pairs this interface doesn't support.

I'm not sure how to deal with the possibility that these might be in use one
day. So far I've ignored that risk in the API. Another approach would be to
add lots of more fields to the struct (as defined by the RFCs), with the
majority of them always set to NULL...

> * I don't really understand the need for SENDFUNC.
>
> Why wouldn't I just provide a 'Cookies:' header with curl_easy_setopt when
> setting up the request? It certainly adds a 'completeness' to the API, but
> it seems quite complex to set up (and to implement!) for no obvious benefit.

The idea would be to allow an application to completely replace libcurl's
cookie engine, and since it has to be able to produce a set of cookies for
every request, including ones when FOLLOWLOCATION is set, just leaving it for
the app to set Cookie: headers is not 100% covering.

Of course, one can argue if it really matters if we cover redirects properly
or not for this edge-case.

-- 
 Daniel Stenberg -- curl: been grokking URLs since 1998
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php