[webkit-dev] CookieJar needs client interface?

[Mike Marchywka]

----------------------------------------
> From: abarth at webkit.org
> Date: Tue, 9 Mar 2010 06:54:32 -0800
> To: superstippi at gmx.de
> CC: webkit-dev at lists.webkit.org
> Subject: Re: [webkit-dev] CookieJar needs client interface?
>
> Implementing cookies is surprisingly subtle, mostly because the
> protocol is quite brittle. If you're implementing your own cookie
> store, a decent starting point might be to look at:
>
> http://src.chromium.org/viewvc/chrome/trunk/src/net/base/cookie_monster.cc?view=markup
> http://tools.ietf.org/html/draft-ietf-httpstate-cookie
>
> Note that the licensing of cookie_monster is a bit complicated because
> it's based on Mozilla's implementation and so carries Mozilla's usual
> tri-license. The spec is a work in progress, but fairly complete at
> this time.

I wrote one from scratch but tried to document sources of wisdom
such as any standards used or "this is what wget/curl left in their
cookie files" or "this dosn't work on foo" etc. I'm glad someone
else thinks this is "subtle." The ietf doc you cite is only  a few
months old and claims to obsolete rfc2109 but that
claims to be obsoleted by http://tools.ietf.org/html/rfc2965 which I apparently used
as a guide.  ) . Is there a list of  "Standard Bugs" (probably
IE LOL) that are often emulated?  Just looking at comments in your code link,
some of those browser issues sound familiar - we were getting
sites sending the same oookie header 50 times and putting
in spaces or other things in odd places.

( Also, I thought I was clever for calling it a cookie monster too LOL).

In our case, with a limited resource target platform ( phones)
we should have devoted more attention to management- not just
deleting old stuff but generally setting some limits and having a removal
policy.

I guess another thing I've seen come up is general issues with data structs
for headers. Hashtables seem to be popular now and don't support
duplicate headers, such as multiple cookie's, so you need to concatenate
all the dups. I think originally our cookie handler had a problem
with this as it expected each cookie in a sep header but probably it was because I hadn't originally coded
it rater than inherent problems with spec or implementation by servers( spending hours hitting my own code stub is really annoying LOL). 

I also seem to recall there may have been  an issue with cookies set from non-200 responses
but again I think that was just a code bug, not a subtly.

>
> I'm not sure whether we want to have a cookie implementation in WebKit
> proper. By and large, we try to use operating system libraries
> whenever possible. If we did, we'd want to think carefully about the
> interface so that it could be used by the network stack directly
> (i.e., for network requests that didn't originate within WebKit).
>
> Adam
>
>
> On Tue, Mar 9, 2010 at 1:19 AM, Stephan Assmus  wrote:
>> Hi all,
>>
>> I am currently implementing the cookie jar backend for the Haiku port and
>> browser. Looking at the other implementations, most of them do it in their
>> network platform code, many are still incomplete. Isn't handling of cookies
>> something browser specific? Looking at the Qt port, it seems like a drastic
>> layering violation, using classes from WebKit in WebCore. So I was
>> wondering if this shouldn't be implemented in a similar pattern to other
>> "client" interfaces. With a CookieJarClient which has to be implemented in
>> WebKit support code, thus allowing a WebKit client specific change of
>> behavior with a clean separation of layers. Is this a good line of thought
>> and is there any interest in something like this?
>>
>> I have set up build environments for the GTK port, Haiku of course and I
>> could also get the Qt port compiling. So that I could try to provide
>> implementations for at least these platforms. Another approach could be to
>> provide the implementation for Haiku only, so that other ports could adopt
>> this scheme if and when they want. Assuming of course that this change is
>> at all desirable.
>>
>> Best regards,
>> -Stephan
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 		 	   		  
_________________________________________________________________
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
http://clk.atdmt.com/GBL/go/201469229/direct/01/