[webkit-dev] CookieJar needs client interface?

[Adam Barth]

On Tue, Mar 9, 2010 at 8:21 AM, Mike Marchywka <marchywka at hotmail.com> wrote:
> 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."

That is the historical technique for writing a cookie implementation.
Unfortunately, that leads to subtle interoperability problems.  I
would encourage you to implement
http://tools.ietf.org/html/draft-ietf-httpstate-cookie exactly as
specified.  A number of people have put significant effort into that
document so that if you follow it's requirements your cookie
implementation should actually work.

> 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.  ) .

You'll be better off if you pretend rfc2109 and rfc2965 don't exist.
I suspect they're doing more harm to your implementation than good.

> Is there a list of  "Standard Bugs" (probably
> IE LOL) that are often emulated?

http://tools.ietf.org/html/draft-ietf-httpstate-cookie document what I
and the cookie working group at the IETF currently believe are the
best trade-offs with respect to implementing the cookie protocol
today.

> 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.

That code is very close to the requirements in
http://tools.ietf.org/html/draft-ietf-httpstate-cookie, as are the
Firefox and IE implementations.  Curl is far from correct and, IMHO,
not a good model to work from.

> ( 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).

You'll need to be able to represent duplicate HTTP headers to process
HTTP responses correctly.

> 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 aware of this issue, but I'd be interested to learn more if
you have more details.

By the way, there's also a test suite available for the cookie
protocol, which you can find out more about here:

http://github.com/abarth/http-state/tree/master/tests/

Adam