On Tue, Mar 9, 2010 at 8:21 AM, Mike Marchywka <[email protected]> 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 _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
