I think this is the exact difference. `curl -I` makes a HEAD request while the other is making a GET request and showing the response header. Just as a f'instance against a machine running nginx on my local network: the GET response sends me a Transfer-Encoding in the response header while a HEAD request does not. I can see a lot of configurations where a HEAD request returns different headers than a GET.
> However, a server MAY omit header fields for which a value is determined only while generating the content.
I find omitting Transfer-Encoding quite understandable and reasonable; the whole purpose of HEAD is to say “don’t bother doing the work that GET would trigger, I don’t care about exactness, I’m just getting a general idea”. Though I do find cases where Content-Length is omitted, even on static resources, disappointing. Saw that happen for I think the first time a few weeks ago (that is, a Content-Length that was present in GET but absent in HEAD).
But certainly I’ve seen more than a few 405 Method Not Allowed responses to HEAD, which is definitely bad.
