摘要

  • RFC 2324 用 BREW/POST 和 start/stop 表达咖啡壶控制意图；服务器接受消息，只证明协议边界内的处理。
  • 配套 RFC 2325 分别暴露容量、运行状态、液位、时间和温度，但没有定义“已出杯”“已交付”“合规适饮”或“已被饮用”的对象。

一次成功响应只关闭了一个问题

设想最顺利的请求：客户端找到正确的 coffee: URI，用 message/coffeepot 发送 start，服务器识别 BREW，也没有返回 406 或 418。此时能确认的是，某个控制端接收并处理了它声称支持的命令。

尚未确认的事情更多：加热器是否通电，水和咖啡粉是否存在，水温是否达到要求，液体是否穿过滤网，咖啡壶和杯子是否就位，以及饮料是否到达预期的人。RFC 2324 把动作写进协议，却没有把动作之后的世界写成一个状态码。

这份 1998 年 4 月 1 日发布的文档属于 Informational，并明确不是 Internet 标准。它以戏仿方式在 HTTP 上增加方法、头字段、返回码和 URI。笑点之下有一条严肃边界：协议可以精确定义“如何提出请求”，却不能凭定义本身制造执行证据。

请求体尤其克制，只允许 start 或 stop。发件记录说明客户端表达了什么；访问日志说明服务器收到什么。两者都不是电流、温度、液位或出杯传感器。把它们改名为“咖啡完成”，等于把希望写回日志。

能力拒绝不是结果测量

HTCPCP 允许客户端用 Accept-Additions 描述可接受的牛奶、糖浆、甜味剂、香料或酒类。操作者无法满足时可以返回 406，并列出可提供的添加项。向茶壶请求冲咖啡，则应得到著名的 418 I'm a teapot。

这两种响应都很有用，但问题很窄。406 说明请求的组合超出可供范围；418 说明目标设备类型不匹配。没有收到 406，不能推出奶已经加入；没有收到 418，也不能推出咖啡粉、水和杯子已经准备好。

Safe 字段同样只回答重试问题，甚至可以附带“用户已醒”等条件。RFC 自己指出，设备的实际安全性可能取决于客户端条件。重试安全不是食品安全，也不是卫生、过敏原、法规或适饮温度的证明。

GET 的安排把边界说得更直白：咖啡壶资源是物理的，而大多数咖啡 URI 返回的数据并不含咖啡因。表示可以描述物体，但表示不能倒进杯子。

MIB 增加了观测面，也增加了解释责任

同日发布的 RFC 2325 为咖啡壶设计了 MIB。它分别列出设备容量、壶型、位置、运行状态、液位、计量单位、预约启动时间、启动后经过时间和温度。

这些字段不能互换。容量指设备支持多少单位，“不论当前状态如何”，所以十二杯容量的壶可能是空的。brewing 是运行状态，不是产量。液位必须和杯、马克杯等单位一起解释。温度是某处的读数，不等于整条流体路径洁净，也不等于对某人适饮。启动后经过时间更不能证明液体已经流出。

可靠的证明链要把请求、设备、同一次运行、执行器、状态、液位和温度关联起来；随后还要观察液体进入容器、容器交给谁、适用的安全或合规检查，以及在真正需要回答时的实际饮用。任何缺失环节都应保持未知。

418 留下的是文化事实

RFC 9110 后来把 418 标为未使用并予以保留，因为这个玩笑代码已经被部署得足够广，无法干净地另作他用。这证明一个符号进入了软件和工程文化。

它不证明咖啡壶采用率，更不证明任何一次冲煮。登记表负责稳定共享语义，不负责替设备、传感器或人作证。文档发布、代码实现、物理运行、出杯交付和人类消费，是五种不同事实。

来源