(This may have been an inadvertent change, I don't remember but I also don't find any explicit commit saying this.)

The problem is that without a specific domain for the cookie, curl won't know for what sites to use the cookie and it would then presume it is for all domains you specify on the command line, and that's probably not many users want. The internal cookie engine needs a (single specific) domain to "attach" the cookie to.

The solution is to store cookies with -c as a cookie-jar instead of just saving HTTP headers with partial information.

This is a behavior change and as such it is a bug, but I don't think this is one that we'll benefit a lot by fixing. Especially not if it has been this way for 2.5 years already...

Actually, I think we have to fix it. Cookies with the __Host- prefix are not allowed to have a domain attribute.

I'm taking a crack at this, along with some other cookie related things I had on my TODO while in there.

I doubt I'm adding any value here, but I was changing code that had been passing the cookie like this:

martind@pizzagate:/tmp/curl-7.60.0$ ./src/curl --silent --verbose --cookie key=value http://blank.org/ 2>&1 | grep Cookie
> Cookie: key=value
martind@pizzagate:/tmp/curl-7.60.0$ 

That works in all versions of curl that I tried, so there must already be some code path that's happy with at least one cookie without a domain (perhaps that's what @danielgustafsson told us already). My goal was to hide the cookie's value from the process list. I did read:

As a convenience, curl also supports a cookie file being a set of HTTP headers that set cookies. It's an inferior format but may be the only thing you have.

... from https://everything.curl.dev/http/cookies but the cookiejar format from https://curl.se/docs/http-cookies.html made me think "surely I don't need that complexity". I was sad not to be able to use <filename with --cookie like I was using with --form.

I was sad not to be able to use <filename with --cookie like I was using with --form.

You mean by using that specific syntax? The command line tool is unfortunately wildly inconsistent in how you specify a file to read vs plain content, when the same option can do both.

You mean by using that specific syntax?

I don't think I even tried that before disabusing myself of that hope from the man page. The man page did hint that I might need a "Set-Cookie: " prefix in the file, but it was subtle enough that I don't think I took the hint without StackOverflow's help. A comment on StackOverflow then misled me into thinking I needed a semi-colon on the end. I'm not sure where I learned that I did need a newline on the end - otherwise no cookie is sent, though there's no warning to say "I spurn your half-baked --cookie!". Ooh, I see the man page does clearly state that omitting the domain is allowed:

If you use the NAME1=VALUE1; format, or in a file use the Set-Cookie format and don't specify a domain, then the cookie is sent for any domain

The man page did hint that I might need a "Set-Cookie: " prefix in the file

...

I'm not sure where I learned that I did need a newline on the end

The man page says:

The file format of the file to read cookies from should be plain HTTP headers (Set-Cookie style) or the Netscape/Mozilla cookie file format.

... and cookie headers ("Set-Cookie style") of course need to be headers and a HTTP header always ends with a newline. In my mind that is clear but perhaps that should be clarified better.

I now assume that when you talked about <filename you meant that the file in question would only contain "name=value" ?

If you only did this to hide the cookie from PS output you could instead go with:

echo "-b name=value" | curl -K - $URL

you meant that the file in question would only contain "name=value" ?

Indeed. I'd value a single example in the man page, one that stopped me fretting over whether a Set-Cookie: header includes the Set-Cookie: bit or the trailing punctuation, one that would help users of existing versions too, over that ~suggestion.

echo "-b name=value" | curl -K - $URL

And because echo is a shell builtin, it won't appear in ps, even fleetingly - how cunning.

At the point in time when libcurl reads the cookie file from disk it hasn't parsed the provided URL yet so it doesn't even know what host name it will use from there and therefore it cannot easily use that as for example a default domain for headers stored without it.

I'll keep my position that I think we should rather document this behavior and urge people to not load cookies from stored HTTP headers but instead use the more "appropriate" cookie jar format for that purpose. Or provide the domain property if the HTTP headers are generated by something else.