Wrong cookie merging

[na--]

This script (copied from here):

import http from "k6/http";

export let options = {
  iterations: 2,
};

export default function () {
  // Set cookies
  if (__ITER === 0) {
    let resp1 = http.get("https://httpbingo.org/cookies/set?key=value1");
    console.log(resp1.body);
  }

  // Check cookies
  let resp2 = http.get("https://httpbingo.org/cookies");
  console.log(resp2.body);

  // Check custom cookies...
  let resp3 = http.get("https://httpbingo.org/cookies", {
    headers: { "Cookie": "key=value2;anotherkey=anothervalue" }
  });
  console.log(resp3.body);
}

will produce

{"key":"value1"}
{"key":"value1"}
{"anotherkey":"anothervalue","key":"value1"}
{}
{"anotherkey":"anothervalue","key":"value2"}

And I haven't tested how passing cookies or jar in the http.Params object plays into the whole mess... Since we already have way too many ways to specify cookies, we should at least fix them so merging the cookies works like how most users would expect it to work, and we should also explicitly document the precedence order and verify it with tests...

[mstoykov]

For the record if you dump the request headers with --http-debug you can see that actually the value that is sent for the third request is

Cookie: key=value2;anotherkey=anothervalue; key=value1

So it is ... technically merged ;).

edit: I seem to have run some experiment that "proved" the below but later investigation suggest it is just not true and I probably got confused due to the example being more complex than necessary 🤦

Additional problems are

  let resp2 = http.get("https://httpbingo.org/cookies", {cookies: {key2:value}});

Would actually set key2 to value in the VU's jar

I actually came around this while looking at the code working on #1650 and #1226, and I think we need to actually agree on what the behaviour needs to be so I can do it right for the was codebase and then backport it to the HTTP one ...

[imiric]

I recently looked into this while trying to answer a support question with the httpx JS lib, and the behavior is indeed confusing and inconsistent when mixing the Cookie header with the cookies request option property.

In order to simplify things for the new HTTP API, I think we should abandon any smart merging when specifying the Cookie header, and simply send the header as specified, overriding any previous cookies, jars, etc. If the user wants to set the header directly, then we should assume that they want to explicitly override it.

Otherwise, if they want to do any merging, then they should use the cookies property instead, which allows specifying if a cookie should be replaced or not. This also gives us a structured object to work with, that would make merging easier, instead of having to parse stringy header values.

[mstoykov]

It seems that while confusing for us - no users have come around to say something in the 4 years of this issue.

The new http design already specifies that this will just overwrite cookies as @imiric proposes above.

So I will close this