[webkit-dev] CookieJar needs client interface?

[Adam Barth]

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'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 <superstippi at gmx.de> 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
>