正文阅读
HTTP 204 没有正文是故障吗？分清空响应与连接失败
客户端健康检查显示成功，浏览器打开同一地址却是一片空白；或者程序收到响应后报“JSON 解析失败”。遇到这类情况，先看 HTTP 状态是否为 204 No Content，不要马上把它解释为机场断流。
本文适用于已经收到 HTTP 响应的排障。若连状态码都没有，应该先检查解析、连接、TLS 或本地超时。
204 本来就不返回正文
RFC 9110 规定，204 表示服务器已成功完成请求，没有额外内容可发送；响应在头部结束处终止，不能包含响应内容或 trailers。因此一个合规的 204 响应没有 JSON，也没有页面正文。RFC 9110：204
它可以用于某些成功保存或删除的接口，也可出现在采用无正文响应的连通性检查中。具体接口是否应返回 204，要以该接口文档为准，不能要求所有成功请求都必须返回 200 和一段文字。MDN：204
把三种“空”分开记录
| 现象 | 能确认什么 | 下一步 |
|---|---|---|
| 收到 204，正文为空 | 有一条无正文的成功响应 | 核对该接口是否按设计使用 204 |
| 收到其他状态，正文为空 | 收到了响应，但语义由状态和方法决定 | 同时查看请求方法、响应头和接口文档 |
| 没有收到 HTTP 状态 | 尚不能证明 HTTP 请求完成 | 根据客户端错误查连接或超时阶段 |
不要使用“空文件”作为唯一判据。HEAD 方法也不会传回响应正文，但它和 204 的含义不同；正常 GET 到业务页面是否该有内容，需要单独验收。
一次低风险核对流程
- 先确认这是公开测试地址还是业务 API。对登录、付款、删除和上传请求，不要为了排障反复重发。
- 在浏览器开发者工具的网络面板，或客户端的请求记录中，读取请求方法、状态和响应头。
- 若是 204，核对接口文档是否要求无正文。若程序强制把响应解析成 JSON，应按接口约定调整处理逻辑，而非添加不存在的数据。
- 再用正常业务页面执行一次只读操作，确认实际工作能完成。不要把一个健康检查地址成功视为所有网站都可用。
记录模板可以写成：“目标属于公开只读接口；方法 GET；状态 204；正文零字节；业务页面另行验证成功或失败。”客户端若还报告错误，要把错误文字单独保留。
为什么测试绿灯不等于业务验收通过
健康检查往往只覆盖一个测试目标。它可以验证这次请求得到了预期响应，却无法代表其他域名、文件上传、长连接或账号接口的表现。
做机场推荐或试用比较时，保留同一测试目标作为基础，再加入你真正需要的业务。不要把204的空正文当坏消息，也不要把204的成功当作全部业务的保证。
验收方法
完成排查后应能分别回答：有没有收到响应；该方法与状态是否符合接口约定；真实业务是否完成。三项结果各自明确，才不会把协议正常和应用处理错误混为一谈。
评论