We are currently implementing cookie support in our port. In order to do
so I had to figure out how WebKit expects cookies support to be handled.
In my copy of CookieJar.cpp I wrote the notes below, which I think are
close to being correct.
If you are using something like Curl then Curl handles cookies itself
except I believe the CookieJarCurl.cpp code is wrong because it has the
cookieJar HashMap below whereas really the functions below need to talk
directly to the Curl cookie manager. The code below is of course also
wrong because it doesn't understand expirations and paths, but I presume
that's obvious to the cookie connoisseur. If you are implementing your
cookie handling, then you need to have your transport handler either
handle the cookies itself like Curl does or you need to have some
independent cookie manager that listens to received headers and is
called by the code below and which can write outgoing headers before
your HTTP code sends them.
///////////////////////////////////////////////////////////////////////////////
// WebKit expects cookie support to be handled by the HTTP transport system
// and WebKit itself doesn't do any work to parse or send cookies, with
two exceptions:
//
// - The HTML of a page has an http header directive in a <meta> tag
within the <head> tag, as with:
// <html><head><meta http-equiv="Set-Cookie"
content="SomeCookie=SomeValue; expires=Sat, 01-Jan-2000 00:00:00 GMT;
path=/"/></head></html>
//
// - The JavaScript of a page directly sets a cookie, as with the
following JavaScript:
// document.cookie = "SomeCookie=SomeValue; expires=Sat,
01-Jan-2000 00:00:00 GMT; path=/"
//
// In either case we have a cookie being specified in the page instead
of the
// HTTP headers and the transport system doesn't see it. So WebKit calls
the
// setCookies function here and expects that somehow this is relayed to
the transport system.
//
// Cookies that come via HTTP headers need to be handled by the
transport system
// or some external entity that gets to see the headers upon receiving them.
// Similarly, sending of cookies is always done via HTTP headers and
need to be sent by
// the transport system or some external cookie management system that
can set
// header entries before they are sent.
//
// So what we need to do is implement cookie support for our transport
system
// and have the functions here tie into it.
///////////////////////////////////////////////////////////////////////////////
// This cookieJar is a stand-in and should be removed. What we need to
do is to relay
// setCookies() and cookies() to the transport system's support for
cookies. Granted,
// an option may be to have the transport system get cookies from
something we write
// here. But in any case we will want something more proper and
persistable than a simple
// HashMap which has no concept of cookie expirations or paths.
static HashMap<String, String> cookieJar;
// This function is called by the Document or JSDocument when the page
itself specifies
// a cookie. We want to relay this to our central cookie manager.
void setCookies(Document* /*document*/, const KURL& url, const KURL&
/*policyURL*/, const String& value)
{
cookieJar.set(url.string(), value);
}
// This function would be called by the application if it wants to put
up a dialog box to
// display the currently recognized cookies for a URI. This is not
currently called by
// the transport system prior to sending an HTTP page request. As of
this writing, our
// application doesn't call this function.
String cookies(const Document* /*document*/, const KURL& url)
{
return cookieJar.get(url.string());
}
// This function would be called by the application if it wants to
display the current setting.
// As of this writing, our application doesn't call this function. It
could also be called if
// the page references the 'navigator.cookieEnabled' DOM property.
bool cookiesEnabled(const Document* /*document*/)
{
return true;
}
// This is called on application shutdown to clear the runtime cookies.
// This could be used to shutdown whatever application-level cookie support
// exists if it is not being managed by the transport system, which probably
// can take care of its own cookie shutdown if it happens to be managing
// cookies itself.
// This function added by embedded developers because otherwise the
cookieJar memory is lost.
void releaseCookies()
{
cookieJar.clear();
}
________________________________
From: David Kilzer <ddkilzer at webkit.org>
$ find WebCore -iname \*cookie\*
WebCore/platform/CookieJar.h
WebCore/platform/mac/CookieJar.mm
WebCore/platform/network/curl/CookieJarCurl.cpp
WebCore/platform/network/soup/CookieJarSoup.cpp
WebCore/platform/network/soup/CookieJarSoup.h
WebCore/platform/network/win/CookieJarCFNetWin.cpp
WebCore/platform/network/win/CookieJarWin.cpp
WebCore/platform/network/win/CookieStorageWin.cpp
WebCore/platform/network/win/CookieStorageWin.h
WebCore/platform/qt/CookieJarQt.cpp
Mmm...cookies.
Dave
________________________________
From: zhenghe zhang <zhenghe.zhang at gmail.com>
Hi all
I want to obtain the "cookie", but I didn't find it in the "webkit"
package.
I hope you help me?
Thank you
zh
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
