[go-nuts] cookiejar changes?

[tandalat]

Hello,

The current implementation of cookiejar.Cookies(url.URL) returns cookies
with only attributes Name and Value being set. It would be more beneficial
if they contain most attributes (with the exception of max-age) set in a
response by the server as this enables code extracting cookies to extend
further processing such as adding persistence storage. I'd prepare a patch
if the request makes sense.

Thanks,
tan

[Nigel Tao]

Post by tandalat
The current implementation of cookiejar.Cookies(url.URL) returns cookies
with only attributes Name and Value being set. It would be more beneficial
if they contain most attributes (with the exception of max-age) set in a
response by the server as this enables code extracting cookies to extend
further processing such as adding persistence storage. I'd prepare a patch
if the request makes sense.

Re persistent storage, there was a lot of discussion with Dr. Volker
Dobler (CC'ed) and I a couple of years ago about how to do a cookie
jar with pluggable storage, but we never landed on a satisfactory
design, let alone a perfect one, so what's in the standard library is
not persistent.

If you come to us with an existence proof of a good design for a
persistent cookie jar, I'm happy to look at it, but in the meantime,
if you want persistence, it''s probably best to fork
net/http/cookiejar for now. Once a change lands in the standard
library and is released, we can no longer change its API, and I don't
know what the right API is yet.

https://groups.google.com/forum/#!topicsearchin/golang-dev/cookiejar$20-%22broken$20by%22
and
https://groups.google.com/d/topic/golang-dev/7Jcbgrbah2s/discussion
might be places to start looking for previous discussions.

[Volker Dobler]

Post by Nigel Tao

Post by tandalat
The current implementation of cookiejar.Cookies(url.URL) returns cookies
with only attributes Name and Value being set. It would be more beneficial
if they contain most attributes (with the exception of max-age) set in a
response by the server as this enables code extracting cookies to extend
further processing such as adding persistence storage. I'd prepare a patch
if the request makes sense.

Re persistent storage, there was a lot of discussion with Dr. Volker
Dobler (CC'ed) and I a couple of years ago about how to do a cookie
jar with pluggable storage, but we never landed on a satisfactory
design, let alone a perfect one, so what's in the standard library is
not persistent.
If you come to us with an existence proof of a good design for a
persistent cookie jar, I'm happy to look at it, but in the meantime,
if you want persistence, it''s probably best to fork
net/http/cookiejar for now. Once a change lands in the standard
library and is released, we can no longer change its API, and I don't
know what the right API is yet.

Yes, a persistent cookiejar with proper error handling will be very hard.

But If I understand Tan correctly he is suggesting to just add some
API to retrieve all cookie entries from the jar. Maybe something like

// UsedETLDs returns all effective top level domains for which
// the Jar contains cookies.
func (j *Jar) UsedETLDs() []string

// CookiesFor returns all stored (and not expired) cookies for
// the given effective top level domain etld.
func (j *Jar) CookiesFor(etld string) []Entry

with Entry some exported form of cookiejar.entry.
(While the two stage retrieval might look strange it has some
benefits.)

Based on this API a user of package cookiejar could extract all
stored cookies and persist them herself. Probably loading them
back into a Jar would require some help to safeguard against subtle
errors and PSL changes.

Coming up with the "right" API here will be difficult, but might be
simpler than a real persistent cookiejar.

V.

Post by Nigel Tao
https://groups.google.com/forum/#!topicsearchin/golang-dev/cookiejar$20-%22broken$20by%22
and
https://groups.google.com/d/topic/golang-dev/7Jcbgrbah2s/discussion
might be places to start looking for previous discussions.