5 ms·

Does anybody know the motivation behind using `curl -sD- -o/dev/null` instead of `curl -I` on the landing page?

• CharlesW 3y ago
  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.)
  • giantrobot 3y ago
    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.
    • chrismorgan 3y ago
      As a matter of standards compliance <https://www.rfc-editor.org/rfc/rfc9110#section-9.3.2-2 https://www.rfc-editor.org/rfc/rfc9110#section-9.3.2-2>: > 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.