I found some time polishing my implementation of the CookieJar
interface in net/http and found the following stumbling blocks:
Handling of public suffixes, handling of IP addresses, handling
of internationalized domain names (IDN) , storage size limitations
exported methods (other than SetCookies and Cookies) and
internal storage of the cookies.
I'd like to discuss this before providing a CL for review.
- Handling of public suffixes  is not complicated, but
requires large tables: There are more than 6000 rules in the
table maintained under . This table might be useless for
lots of use cases.
- Browsers handle cookies received from an IP address
differently than RFC 6265 requires. And different browsers
disagree on the corner cases.
- IDNs require cookie domains to be punycoded. go-idn 
seems natural here. Would go-idn qualify to be incorporated
into the standard library?
- Cookie jar implementations in browsers tend to limit the
amount of cookies stored by dropping infrequently used
- Which extra methods beside SetCookies and Cookies
should a useful cookie jar export?
- Depending on the amount of cookies kept in a jar
different data structures are more efficient. Keeping 10
cookies from 2 domains is a different story than keeping
tens of thousands of cookies from hundreds of domains.
I thought about providing a CL containing a cookie jar
which addresses these issues as follows:
- Ignore public suffixes (allow domain cookies for .com or co.uk).
- Be strict with IP addresses and stick to RFC 6265.
- Ignore IDNs and mark thus as a BUG.
- Do not impose any limits or automatic cleanup actions on the jar.
- Provide the following additional methods:
func NewJar() *Jar // set up epty jar
func (jar *Jar) All() Cookie // returns copy of jar's content
func (jar *Jar) Add(cookies Cookie) // populate/update jar
func (jar *Jar) Remove(domain, path, name string) bool // del.
Pros, cons and rationals:
- Ignoring public suffixes seems okay as long as no one writes
a browser in Go. Ignoring is fast and doesn't require a list of
known public suffixes which gets outdated and consumes RAM.
- Not properly punycoding the domain name is clearly a bug.
The jar will not handle cookies retrieved from an IDN properly.
- I assume (!) that the typical use case requires only a few
cookies from a handful of domains (some session or authentication
cookies). Automatic cleanup or limitations seem unnecessary
on this setup.
- The exported methods allow to serialize the jar with minimal
effort if someone wants to persist it to disc or share over the
network. Remove is a pure convenience methods as it could
be simulated by a call to SetCookies but it seems natural to
have Remove if you have Add (and deleting a cookie with
SetCookies is awkward). All is "inefficient" in the sense of
returning a copy of all cookies. As this might not be the most
common method to call on a jar it seem okay to me.
Any comments welcome!