I just released version 0.8.0 of HttpCookie, a standards-compliant (client-side) HTTP Cookie implementation.
It’s not a new library, but this release resolves the public suffix dependency mess so I thought it’s a good time to spread the word.
The code is tested against implementation-agnostic IETF test cases so I’m reasonably sure the code is correct and I’ve been using it in prod for about a year without issue.
I tried to make it safe by default:
- there’s default limits for the cookie size and number of cookies per domain and in total
- there’s a check to reject ‘supercookies’
It also ships with a Req plugin which makes it easy to use if you already use Req.
So you can really use it at 3 different abstraction levels:
- as a Req plugin
- as a cookie jar with any other HTTP client
- as a cookie string parser (if you have niche needs and/or you want to build you own cookie jar)
Contributions in any form or shape are welcome, and I’d be happy to receive bug reports, feature suggestions and PRs. The standard disclaimers apply - this is a free time project and your contributions might not get noticed/reacted to very quickly.
Backstory
Back in late 2023 I needed to access an API that uses cookies for authentication, so I needed a cookie jar to use with Req.
I found two potential libraries to use: cookie_monster and cookie_jar.
I first tried cookie_jar because it was closer to what I needed, but it failed to parse some cookies I had to deal with and upon further inspection I saw that the cookies were probably following the spec (I didn’t know the spec that well yet at that point).
So then I tried to parse the cookies with cookie_monster and that worked for the most part, except I also found it diverged from the spec when handling unsupported attributes which broke parsing one of the cookies I had to deal with.
I was in time crunch with the functionality that used this so for the time being I ended up with a frankenstein solution of:
- preprocessing the cookie string to remove the ‘Version’ attribute that one of the servers was sending
- parsing the cookie with
cookie_monster - storing/using it with
cookie_jar
Though the issue with the unrecognized attribute parsing was later resolved in cookie_monster I still thought the Elixir ecosystem could use a client-side cookie implementation that more closely followed the spec.
This is not a complaint about the existing libraries and I’m grateful they exist, but I chose to start over and treat this as a learning opportunity. I definitely learned a lot reading the 3 existing RFCs that cover this functionality and being able to experiment freely helped me get to something I feel works well.
Future work
A new cookie RFC that will obsolete RFC6265 is in the works.
It standardizes SameSite which is already implemented by browsers and removes the deprecated Cookie2/Set-Cookie2 headers, so apart from any bugfixes that’s what you can expect implemented in the future - though I might wait for the standard to be finalized to start.
