The problem here is that CURLOPT_ACCEPT_ENCODING set to an empty string has a meaning other than please send a blank header. The man page says:

If a zero-length string is set like "", then an Accept-Encoding: header containing all built-in supported encodings is sent.

So you're really asking for two mutually exclusive things in that request and it's not immediately clear which of the two instructions that should override the other...

Could we perhaps make this clearer in the documentation?

Perhaps it would help to mention that one may set CURLOPT_ACCEPT_ENCODING to a NULL pointer in order to disable it (both sending the header and auto decoding) in case it was previously enabled on the given easy handle.

BTW, I find the statement "identity, which does nothing" to be a bit misleading, as setting 'identity' does in fact enable auto decoding (e.g. if the header was overridden, or if the server sends gzip despite what the client has specified) and regardless, sending the header with 'identity' only isn't exactly nothing.
Also worth mentioning that the content length header received may not match the actual length of the data in case auto decoding is enabled (I reached the above understanding by troubleshooting a customer issue with our app).

Ok, I committed an update to this man page, have a look at CURLOPT_ACCEPT_ENCODING for the new version.

Better? Anything lacking now?

Yea, but take a look at little adjustments: iboukris@7a329b8

Thanks! I merged the second part of that change. I'm not comfortable with adding the "if it was set to something else before you can disable it again with" text. That is sort of implied if you need to disable it, and I would rather not add that extra text for every man page description we have that tells how to switch an option back to default state.

Make sense, thanks!

@rcanavan, you happy with this explanation or are you looking for something else?

Hmm, I've looked again at @rcanavan's example and gave it a quick run, and the behavior actually seem strange indeed.
It looks like if a connection is reused then setting empty "Accept-Encoding:" does not disable sending of the header (if I forbid reused it'd work as expected).
I'll try to take a closer look later on.

But again, you can't both set CURLOPT_ACCEPT_ENCODING (to non-NULL) and ask for disabling the header.

But the doc of CURLOPT_HTTPHEADER says:
If you add a header that is otherwise generated and used by libcurl internally, your added one will be used instead. If you add a header with no content as in 'Accept:' (no data on the right side of the colon), the internally used header will get disabled.

And it does work as one would expect if a connection is not reused.

Perhaps something like this makes it behave more deterministic?

diff --git a/lib/http.c b/lib/http.c
index f3805cc..2a7280d 100644
--- a/lib/http.c
+++ b/lib/http.c
@@ -1915,10 +1915,14 @@ CURLcode Curl_http(struct connectdata *conn, bool *done)
     conn->allocptr.accept_encoding =
       aprintf("Accept-Encoding: %s\r\n", data->set.str[STRING_ENCODING]);
     if(!conn->allocptr.accept_encoding)
       return CURLE_OUT_OF_MEMORY;
   }
+  else {
+    Curl_safefree(conn->allocptr.accept_encoding);
+    conn->allocptr.accept_encoding = NULL;
+  }

 #ifdef HAVE_LIBZ
   /* we only consider transfer-encoding magic if libz support is built-in */

   if(!Curl_checkheaders(conn, "TE:") &&

This works, and it looks correct as well.

That patch does indeed make libcurl behave consistently, not only accross reused connections, but also when adding values to Accept-Encoding: as opposed to trying to unset it. And it is exactly this consistency that I was looking for, and the assurance that other headers, when set first with a value via CURLOPT_HTTPHEADER and then unset, behave just as consistently when reusing a handle.

Yeah sorry for overseeing the consistency argument originally. I've just merged this.

Thanks both of you for your help!