On Fri, 22 May 2015, Alexander Dyagilev wrote:

> "slist" contains the list of my additional headers. One of headers contains
> Cookie field. Its content is:
>
> Cookie: test_cookie_2=base_value2

This means that you UNCONDITIONALLY send that header in the request. You
wanted it, you got it. libcurl passes along what you asked it to pass along.

> I expect libcurl to replace existing cookie I specified in original request
> with the new one.

That's where you go wrong. Your custom headers passed in to libcurl will not
make libcurl parse those headers and look for cookies to add to its internal
cookie stash. They are "just" custom headers you ask libcurl to use. And it
does.

> Instead, libcurl sends both cookies:

Yes, it sends the custom headers you add, and it sends the cookies since you
enabled libcurl's cookie "engine".

> Cookie: test_cookie_2=value2
> Cookie: test_cookie_2=base_value2
>
> Is it a bug?

I'm sorry to simply redirect, but I would say that the bug here is in the
application. The intructions given to libcurl will lead to this result.

> It seems yes according to RFC 6265 (section 5.3, par.11).

It really has nothing to do with RFC 6265. libcurl offers application a very
large degree of freedom to craft and adjust what it does, to test servers, to
override internal behaviors and more. This is just one way your application
can tell libcurl it knows better what to do - even though in this case you
didn't mean to =)

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html