HEAD 方法请求服务器对 GET 会返回的响应，但不会传输响应内容。它适合需要状态、验证器、类型或长度的检查，但前提是元数据与真实的 GET 路径保持一致。

包括 Accept-Encoding 在内的相同请求条件进入 GET 与 HEAD 元数据卡片。只有 GET 连到正文和校验和。HEAD 缺少 Content-Length 不等于失败，提供时应描述对应 GET 内容。小 GET 检查有效载荷，并调查方法分歧与重定向比较范围。
比较 HEAD 与 GET 之前，先对齐 URL、请求头、发布版本与内容编码。允许省略的字段不能自动判为失败。应保留小 GET 的正文或校验和检查，因为看似合理的元数据不能证明有效载荷完好。

比较规范化后的响应头集合

Date 这类动态响应头会随请求不同而变化。只比较描述所选表示的那些字段：

url=https://www.example.test/downloads/manual.pdf

curl -sS -I "$url" > head.headers
curl -sS -D get.headers -o /dev/null "$url"

for file in head.headers get.headers; do
  printf '== %s\n' "$file"
  awk '
    /^HTTP\// ||
    tolower($1) ~ /^(content-type:|content-length:|content-encoding:|cache-control:|etag:|last-modified:|vary:)$/ { print }
  ' "$file"
done

在可丢弃的工作目录运行，因为两个头部文件会被覆盖。对齐 URL、请求头与发布版本；压缩协商也应纳入比较，给两个请求发送相同的 Accept-Encoding 值。

HEAD 应描述对应的 GET，但 RFC 9110 允许省略只有在生成内容时才能确定的字段。单独缺少 Content-Length 不代表失败；如果 HEAD 携带它，其值必须是对应 GET 内容的长度，不能因为 HEAD 没有正文就填零。比较时应统一内容编码，调查变化的验证器与类型，而不是要求两份头部逐字节相同。

不要把 HEAD 当作唯一的发布检查

服务器可能在文件缺失、不可读或被截断时仍合成看似合理的响应头。在冒烟测试里保留一个小的 GET 并核验其正文或校验和。HEAD 降低了传输成本，但并不能证明有效载荷存在。

显式检查重定向

不使用 --location 时，curl -I 报告第一个响应，适合测试重定向策略；使用 --location 时，会打印跟随过程中的多个响应头块，包括中间重定向与最终目标。请记录这条命令回答的是哪个问题：

curl -sS -I --max-redirs 0 https://old.example.test/manual
curl -sS -I --location https://old.example.test/manual

把方法相关的失败视为配置缺陷

一个对 GET 返回 200、对 HEAD 返回 405 或 404 的静态页面，通常暴露出代理或路由的不一致。应当修复方法处理，而不是教监控系统忽略它——除非端点契约刻意不允许 HEAD。

来源