You can be given multiple cookies, all on individual "Set-Cookie:" header lines. They normally have more information than what you're showing... You can't pass back an identical cookie for this reason, there's a proper protocol to follow.

For instance:

Set-Cookie: item=value;Max-Age=N;Path=/

With the provided information, we have a cookie "item" with the value of "value" which expires at age N, and this cookie applies to a Path relevant to the root directory "/".

If we made a request which applies to this cookies path, we must return this cookie within our own request header, minus the additional information. If our request path does NOT apply to the relative cookies acceptable path, this cookie should NOT be relayed, but in this cause, the path is "/" which is the root directory, so all paths "/some/other/location/etc.." would apply, so our response would look something like:

Cookie: item=value

Now what if we're delivered multiple cookies that all apply?
like:

Set-Cookie: item=value;Max-Age=N;Path=/
Set-Cookie: item2=value2;Max-Age=N;Path=/

Well now we must combine our request header cookies into a return (although I think it's also possible to submit multiple cookie lines too, haven't read up on http/1.1 protocol in a while)

Which would look something like:

Cookie: item=value; item2=value2

Your Regex capture group appears to not be greedy and find up-to the first ";" and include this within the capture, I do believe the last relayed cookie should not end in a semi-colon.

I've tested this locally and watched the response headers from both Firefox and Chrome, and this is how they both appear to re-represent a stored cookie string. I haven't exploited deliberately sending a crazy amount of cookies to see how it handles what can fit in a "Cookie:" header line, to witness how it might break-up such a long string.

Firefox Test:
Code
GET /cp HTTP/1.1
Host: xxxx
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: https://xxxx/cp/
Cookie: ClientID=xxxx; OtherData=xxxx
If-Modified-Since: Fri, 09 Mar 2018 02:34:29 GMT
Cache-Control: max-age=0


Not sure if this could be a culprit or not. Also, the value's should be unpacked (uri-compliant, the whole + for space, %XX for illegal characters, etc..) but I do believe you aren't re-packing the value from the httpd request response anyways, but that was another thought I had.

I've never used JSON-4-mIRC so I can't help much beyond that, but I have done plenty of API-related things dealing with cookies over http/https with raw sockets, long before the existance of json-4-mirc and $urlget. It's not too terribly difficult if you understand http/1.1 protocol, which is quite an extensive RFC read.

Also you've posted your response as "A-LOT-OF-TEXT" which makes me wonder if you might be getting any line too long errors? maybe you should be hadding these to a table with -b and saving a binvar? If you go that route, make sure to noop $hget(table,item,&bvar) to load it up, then you could /bcopy whatever data you wish to append, then once again /hadd -b it back to the table, to keep extending your cookie tokenized list.