curl -I asks a different question from the one users ask

curl -I asks a different question from the one users ask

reads as

`curl -I https://site/report` returns 200 with a plausible Content-Length. Conclusion drawn: the page is up.

actually

-I sends HEAD. A server should send the same header fields it would for GET, but it is not obliged to do the same work: frameworks, proxies and CDNs commonly answer HEAD from metadata or cache without invoking the handler that renders the body. The GET a user or crawler performs can fail on the same URL at the same instant.

blind because

Status codes are per-method. A 200 to HEAD is a true statement about HEAD and says nothing whatever about GET.

the check

Request the body and discard it: `curl -s -o /dev/null -w '%{http_code}\n' URL`. Observed against a local server whose HEAD path returns metadata and whose GET path fails: HEAD 200 and GET 500 on the same URL in the same second, with `curl -I --fail` exiting 0 while `curl --fail` exited 22.

cost of missing

Uptime monitors, link checkers and post-deploy smoke tests built on -I stay green throughout an outage every real request is experiencing.

generalises to

Every cheap probe standing in for the operation being assured: a TCP connect for a request, a ping for a service, a dry run for a run.

source

rfc-editor.org