@qZanity Can you show us some code?

/cc @vdobler too

I cannot reproduce the problem. See https://play.golang.org/p/U6l6-5T54ds

@qZanity Maybe the underlying case of the problem you experience is not in the cookiejar but somewhere else? And maybe you could clarify what exactly you mean with

cannot be manipulated programmatically using func (Jar) Cookies

Note that Cookies() just reads cookies stored in the jar, it even returns copies of the cookies and cannot be used to modify the jar or cookies stored in it. The only way to modify cookies in the jar is through SetCookies. For deletion you need to set something like http.Cookie{Name: "nameofcookie", Value: "", MaxAge: -1}.

From my point of view it works as intended.

Thanks to everyone acting quickly on this.

@vdobler I checked your snippet and yes no issues there.

But check this: https://play.golang.org/p/7VP-SKwUlO5

This is a simple implementation using CookieJar with http.Client. You can see that after I SetCookie() a duplicate cookie is created and sent in the next request. I can't get my ahead around why this is happening? To me it looks like a bug, But its seems to be site specific. My development server is local, so I've used Adidas as an example here and it behaves the same way.

Cheers.

The sample helped.
If you add a fmt.Printf("Jar %#v\n", jar), you will see what is going on.
There are 2 domains rather than what you expected.

www.adidas.co.uk;/;_abck":cookiejar.entry{Name:"_abck", Value:"test",
adidas.co.uk;/;_abck":cookiejar.entry{Name:"Value:"4EC318FFD79589413220DF05332AB30AC7EFB7199A1B000031B4BB5AB0C1B578

No, sorry this is not a bug.

You have been tripped by a common misunderstanding regarding the
identity of a cookie: The identity of a cookie is not determined
by its name alone but by the tripple (name,path,domain) in a browser
(or its cookiejar). So you can have douzens of cookies with the
same name if they differ on path and/or domain.

The following explanation is not correct in each and every
technical detail but provides a valid overview.

While the name is always given explicitly the path and domain of
a cookie are often determined implicitly from the URL. The _abck
cookie gets its path from the URL but its domain is set in the
response Header which looks like
Set-Cookie: _abck=4ACB08[...]; [...] path=/; domain=.adidas.co.uk
(which makes _abck a domain cookie instead of a host cookie for
www.adidas.co.uk).

If you just do a SetCookie with a different domain (in your case
the implicit domain extracted from the URL) you store a new, different
cookie. The fact that this new, different cookie has the same name
like the existing is of no concern here: Cookie identity is based
on the whole tripple of name, path and domain.

To fix you atempt to modifiy a cookie in the jar you have to
mimick what the Set-Cookie header does, something like

// Now lets manipluate one of the cookies. FIXED
cookie := &http.Cookie{Name: "_abck", Value: "test", Domain: ".adidas.co.uk"}
jar.SetCookies(cURL, []*http.Cookie{cookie})

But pay attention: This would not only update the Value of the
stored cookie but also its expiration time. With the current
Jar implementation of the standard library it is impossible to
get the information needed to update a cookie out of the Jar:
You have to remember the details (name, path, domain) of how each
cookie was stored to modify it afterwords by providing the same
identity tripple. (There are stlib Jar clones out there which
allow complete data retrieval. I could recommend one :-)

The result of Cookie() with several cookies with the same name
looks strange but is okay, actually even required by the spec.
The order of such same-name-cookies is even deterministic and
specified.

So it's not a bug, Jar works as required by RFC 6265 (which is
complicated and not widely known).

@fraenkel @vdobler

Totally understood and thanks for pointing that out, That was actually my first suspicion but and i actually modified the URI myself, obviously due to the 301 redirect it was still reverting back to the other domain thus creating two cookies.

Thanks for the explanation, Solved.