I don't think it can be seen as anything else than an oversight that we cannot switch off the cookie engine for an easy handle once it has been turned on.

But if we are to introduce such a way - and I think we should - maybe it would make more sense to follow the previous pattern of "cookie commands" that we support with CURLOPT_COOKIELIST and add a switch off command there? Maybe just call it OFF ?

maybe it would make more sense to follow the previous pattern of "cookie commands" that we support

the fix would probably be simple, however CURLOPT_COOKIEJAR I don't see a good way to do the same because data->cookies may be used by a share handle i think

diff --git a/lib/setopt.c b/lib/setopt.c
index 022dd38..4612c03 100644
--- a/lib/setopt.c
+++ b/lib/setopt.c
@@ -752,6 +752,10 @@ CURLcode Curl_vsetopt(struct Curl_easy *data, CURLoption option, va_list param)
       }
       data->state.cookielist = cl; /* store the list for later use */
     }
+    else {
+      curl_slist_free_all(data->state.cookielist);
+      data->state.cookielist = NULL;
+    }
     break;
 
   case CURLOPT_COOKIEJAR:

the fix would probably be simple

This just clears the list of files to read cookies from. It would also need to clear all the cookies from memory and switch off further cookie handling.

IIRC the cookie engine isn't turned on by CURLOPT_COOKIEFILE until the transfer is started

Right, but what if the handle was already used for one or more transfers with cookies and then you switch it off...

I see what you're saying. I don't think the cookie engine should explicitly be shut off by CURLOPT_COOKIEFILE, NULL, but it probably should clear the filenames. The doc doesn't say NULL shuts it off.

For what it's worth, I would expect setting it to NULL to turn it off and here's my reasoning: the default is documented as NULL and if all I do is set CURLOPT_COOKIEFILE to some path and then set it back to NULL without doing anything else, I would expect the easy handle to behave the way it would if I had left things in the default configuration.

I think there's a lot of sense in that reasoning...

Proposed approach in #6891