bisected to c1c2762 which added bold header support but removed setting CURLOPT_HEADER on config->no_body.

This should fix it but I'm not sure what it would break, also tests would need to be adjusted:

diff --git a/src/tool_operate.c b/src/tool_operate.c
index 5a72b6a..1e5743c 100644
--- a/src/tool_operate.c
+++ b/src/tool_operate.c
@@ -864,8 +864,15 @@ static CURLcode operate_do(struct GlobalConfig *global,
           my_setopt(curl, CURLOPT_INFILESIZE_LARGE, uploadfilesize);
         my_setopt_str(curl, CURLOPT_URL, this_url);     /* what to fetch */
         my_setopt(curl, CURLOPT_NOPROGRESS, global->noprogress?1L:0L);
-        if(config->no_body)
+        if(config->no_body) {
           my_setopt(curl, CURLOPT_NOBODY, 1L);
+          my_setopt(curl, CURLOPT_HEADER, 1L);
+        }
+         /* If --metalink is used, we ignore --include (headers in
+            output) option because mixing headers to the body will
+            confuse XML parser and/or hash check will fail. */
+        else if(!config->use_metalink)
+          my_setopt(curl, CURLOPT_HEADER, config->show_headers?1L:0L);

         if(config->oauth_bearer)
           my_setopt_str(curl, CURLOPT_XOAUTH2_BEARER, config->oauth_bearer);

And file does not handle CURLOPT_NOBODY on its own which is why the body is being shown

which seems to me should be

  if(data->set.opt_no_body) {
    if(fstated) {
      if(data->set.include_header) {
        ...
      }
      if(!result)
        /* set the file size to make it available post transfer */
        Curl_pgrsSetDownloadSize(data, expected_size);
    }
    return result;
  }

I think the latter part is what needs to be fixed, as I believe the upper part breaks other things...

The latter as I wrote it should only correct the issue of the body being shown when it shouldn't be, the headers would still not be shown unless CURLOPT_HEADER is set.

curl -I localhost shows the headers so I would probably say that curl -I file:///usr/share/dict/words should also show the headers. (without --include I mean)

Right, that is the regression, it is documented that way. If the bold code now goes through the header callback though I may have broken something else by setting CURLOPT_HEADER, I didn't try this out yet.

Right, that's exactly what I'm thinking. The header output logic was slightly changed with that bolding...

I've just noticed that macOS curl 7.43.0 had a different bug. curl -I works as expected, but curl -i does not report both the headers and the content as expected.

Observed

❯❯❯ curl -I file://$PWD/hello
Content-Length: 14
Accept-ranges: bytes
Last-Modified: Wed, 03 Oct 2018 17:31:42 GMT
❯❯❯ curl -i file://$PWD/hello
Hello, world!

Expected

❯❯❯ curl -i file://$PWD/hello
Content-Length: 14
Accept-ranges: bytes
Last-Modified: Wed, 03 Oct 2018 17:31:42 GMT

Hello, world!

-i is not documented to work with file. there may be some undocumented behavior that varies depending on the version.

Feature request then: could -i and -I work with file://?

-I not working for file is a bug which we'll fix but -i iirc was really intended just for HTTP headers. In the short description it shows as "Include protocol response headers in the output" which could imply other protocols, so I'm on the fence on that one.

curl -i for file:// is not terribly important for me. It's just for consistency. I'd also be okay with documenting that it doesn't work. curl -I for file:// is important to me.

Thanks for fixing this issue, Daniel!