[webkit-dev] Curl Cookie Handling

[Kenneth Christiansen]

I would definately be interested in this work for my EFL port of WebKit.
Currently we use cURL and do not support cookies. Libsoup is apparently a
no-go as I was told that it requires a running glib mainloop.

Cheers,
 Kenneth

On Tue, Feb 10, 2009 at 12:08 PM, Julien Chaffraix <
julien.chaffraix at gmail.com> wrote:

> Hi Kevin,
>
> > Is this patch still valid, i.e. not made obsolete by another approach?
>
> As far as I know, there is no work towards storing the cookies inside
> the database as it is done in Firefox. Furthermore I know no work in
> cURL toward exposing the cookies so that we could add / remove /
> update them simply in our database.
>
> This patch may be a bit special because it is not really cURL
> specific. The only dependency to cURL is a method to parse a date (the
> 'max-age' field), which I found later is already in JavaScriptCore and
> would need to be exported to WebCore and maybe need to be adapted.
> Thus it could be a base toward a cross-platform cookie implementation.
> I do not know if it would be ok for all ports to replicate their
> network library's cookie engine.
>
> > Also,
> > was it a complete patch (sans any bugs, of course) for cookie support
> using
> > SQLite? I could only test it using wx right now but I would definitely be
> > interested in using the SQLite approach.
>
> It is a complete patch in the sense that it stores and fetch the
> cookies from the database. About the bug-free part, we have an answer
> in this thread I guess :-)
> Basically I could not find a test suite for cookies to validate the
> approach when I started so I tested it with real world websites
> (mostly google app suite, yahoo, mapquest and a few other sites) but
> it did not get the testing it deserves and I will not hide it.
> To get it moving, I think a rewrite is necessary because I made tons
> of small mistakes (I started as a contributor at that time and did not
> know the code and coding conventions as I do now) that could be more
> easily tackled by a rewrite. It will also need a test suite to fully
> valide the changes.
> All in all, it means a lot of work that I am willing to do it *if* I
> see enough interest in a cross-platform cookie engine for WebKit.
>
> > I know someone a while back proposed a strategy for dealing with port
> > enhancements that end up bit rotting in the review tree, whatever
> happened
> > to that? Sometimes new feature patches cannot be broken down into smaller
> > pieces, and I realize large patches tend to be intimidating especially to
> > people who can't test them themselves, but there has to be some strategy
> for
> > dealing with that so that important new stuff doesn't just sit in a patch
> > tracker for months or years...
>
> I think you refer to the Gtk port here? IIRC the main issue for Gtk
> was validating the API which is not relevant here.
>
> Regards,
> Julien
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090210/46f04cb3/attachment.html>