摘要

  • 1997 年的 HTTP/1.1 用 205 Reset Content 表示请求已经完成，客户端应把触发请求的文档视图恢复到初始状态。
  • 这条响应不带新内容；2014 年和 2022 年的规范进一步写清了表单、记事板、画布等输入场景及空响应的边界。

窗口后的人接过填满的表格，放进档案柜，转身又递出一张空白的。“下一位。”手续办成了，桌面却像什么都没发生过。早期 HTTP 给这套动作留了一个状态码：205 Reset Content。

1997 年 1 月的 RFC 2068 说得很直接：服务器已经完成请求，用户代理应重置发起该请求的文档视图。它举的例子就是反复录入表单：人填写、提交，表单清空，好继续下一项。这里同时发生两件事。服务器一侧收下了本次输入；浏览器一侧把操作台还给下一次输入。

“重置”指向的是屏幕上的工作空间。提交出去的数据已经进入请求，服务器的完成状态不会因为输入框清空而倒退。规范禁止在 205 响应中携带实体，于是服务器无需送来一张替代页面。状态行已经说清这次工作结束，以及页面下一步该怎样摆放。一个空响应也能指挥相当具体的界面动作。

1999 年 6 月的 RFC 2616 沿用了这个清空表单的场景。隔壁的 204 No Content 则让当前视图留在原位。两条响应都不靠新正文讲故事，后续动作却不同：一条保留台面，一条把台面恢复成待填写的样子。对于一上午要处理几十份录入的人，205 的意义就在这段节奏里。交一份，空出来，再交一份，中间少一次换页的等待。

到了 2014 年的 RFC 7231，规范把“视图”描述得更精细：恢复到从源服务器收到时的原始状态。输入区域可以是表单，也可以是记事板或画布。用户在上面输入或操作，发出请求，再得到一个可继续使用的起点。那不是抽象的“成功”；它描述了人如何把一个任务接到下一个任务。

同一版规范还处理了空响应在网络上的收尾方式。205 不得生成载荷。服务器可以发送 Content-Length: 0，也可以用一个零长度分块结束分块传输，或者在响应头的空行后关闭连接。这些细节没有窗口叫号机那样显眼，却决定接收方何时确认本条消息结束。屏幕能否准备下一份，先要把本条网络消息的边界认清。

2022 年的 RFC 9110 保留了 205 的基本安排：请求已履行，用户代理恢复原始视图，响应没有额外内容。互联网换过很多外观，重复录入的逻辑却一直朴素。完成的事情留在服务器，下一件事从干净的输入面板开始。

205 的幽默感在于它的冷静。你辛辛苦苦填完，屏幕立刻把空表递回来；它相信你还有活儿。状态码无法替你完成下一份，但它把“办妥”和“继续”之间那一下清台动作，准确地交给了浏览器。