The former appears to retrieve headers via a standard GET request. Apparently, with the latter method, there's a chance you may get different results than you would see from a GET request. (I'm not an expert, so this is just what I discovered after digging a bit for curiosity's sake.)
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.
