HEAD 请求成功就能证明下载正常吗？响应头与正文分别验收
只用一条 curl -I 命令得到正常状态，适合说明头部请求的结果，却没有检查文件正文能否完整传完。协议工具回答的范围不同，选购和排障记录也要对应这个范围。
本文适合了解 HTTP 基本请求的人。使用允许访问的小页面或小文件，避免用大型下载来补做一项本来只需要有限流量的验收。
示意图：头部检查与正文验收各有范围，下载任务需检查实际内容。
HEAD 省略了什么
RFC 9110 的 HEAD 定义要求服务端不在 HEAD 响应中发送正文。它可用于获取相关表示的元数据，而不是下载该表示本身。
因此，头部里的 Content-Length 即使不是零，也不能理解为 HEAD 已经收到这么多正文。应把它看作头部信息，再检查你实际执行的方法和收到的内容。HEAD 的字段也不保证与另一时刻的 GET 响应逐项完全相同。
分开保存两种请求
curl 官方手册说明 -I 使用 HEAD 获取头部。不要只用 -X HEAD 改方法名称来替代这个专门选项。
Windows PowerShell 示例，域名用于说明结构：
$target = 'https://example.com/'
curl.exe -q -I --connect-timeout 8 --max-time 20 -o head-response.txt --url $target
$LASTEXITCODE
curl.exe -q --connect-timeout 8 --max-time 20 -D get-headers.txt -o get-body.txt -w 'http=%{http_code} bytes=%{size_download}\n' --url $target
$LASTEXITCODE
目标替换为自己有权检查的小资源，使用未占用的文件名。两轮采用相同网络和已明确的代理路径，分别保存结束状态；它们仍然是两次独立请求，不是同一响应的两个部分。
不同观察对应不同结论
| 观察 | 可以说明什么 |
|---|---|
| HEAD 完成且状态符合预期 | 本次头部请求完成 |
| GET 得到预期正文并正常结束 | 本次正文请求完成 |
| HEAD 正常，GET 中途中止 | 头部结果不足以覆盖传输阶段 |
| HEAD 返回方法不支持 | 该方法的结果，GET 仍需另查 |
| GET 保存了错误说明页 | 收到内容，但不是所需文件 |
不要把 GET 的错误页面当作文件完整性通过。文件类型、正文用途和服务端提供的可信校验信息，都应按你原先要完成的任务核对。
验收重点按用途选择
若只是检查某个公开页面的头部，HEAD 的结果可以有价值；若需求是下载、图片显示或文档阅读，就必须实际检查相应内容。小页面完成也不能证明大型文件在较长时间内都稳定。
建议记录方法、目标、时间、路径、状态、是否有预期正文和退出结果。目标有签名有效期、账号或不同访问政策时，先按正式说明确认测试条件，而不是拿两种不同权限的请求作对照。
怎样用在机场推荐记录里
把“头部可达”“小内容完成”“实际任务完成”分成不同证据项。可以采用这些项目逐步验收，但不能用第一项自动填满后两项。工具越轻量，越需要准确说明它究竟检查了哪一层。
来源与核验日期
官方资料核验日期：2026-10-10。本文的操作与判断方法供读者自行核对，不代表本站对某家机场的实测结论。
评论