418“我是茶壶”真的是HTTP响应代码吗？

418“我是茶壶”真的是HTTP响应代码吗？

互联网上对此有多种引用，包括响应代码列表，但我不知道这是否是一个奇怪的笑话。

我使用此代码。我对两个单独的HTTP服务器有nginx反向代理请求。一种处理对未经身份验证的用户的请求，第二种处理对经过身份验证的用户的请求。在这种特定情况下，问题在于第一台服务器是确定用户是否通过身份验证的服务器。请不要问为什么。

因此，如果第一台服务器确定用户已通过身份验证，它将做出响应418 I'm a teapot。然后，NGINX在内部将流量重新路由到第二台服务器。就浏览器而言，这只是一个请求。

这是本着HTCPCP代码418的精神，因为如果您尝试用茶壶BREW，则适当的响应是“我不是那种可以处理该请求的东西，但是可能还有其他事情。” 换句话说，“我是茶壶。找到咖啡壶。” （第二台服务器是咖啡机）。

最终，虽然418在RFC 7231中未明确定义，但仍被的保护层覆盖4xx (Client Error)。

6.响应状态码

• 4xx（客户端错误）：请求包含错误的语法或无法满足

6.5。客户端错误4xx

• 状态代码的4xx（客户端错误）类表明客户端似乎已出错。除响应HEAD请求外，服务器应发送一个包含错误情况说明以及它是暂时还是永久的说明。这些状态代码适用于任何请求方法。用户代理应该向用户显示任何包含的表示。

HTTP响应代码418最初是在RFC 2324（“超文本咖啡壶控制协议（HTCPCP / 1.0）”）和RFC 7168（“用于茶叶外排设备的超文本咖啡壶控制协议（HTCPCP-TEA）”）中定义的。

每个维基百科：HTTP状态代码列表：＃418

该代码在1998年被定义为RFC 2324（超文本咖啡壶控制协议）中传统的IETF愚人节笑话之一，并且预计不会由实际的HTTP服务器实现。RFC指定此代码应由请求冲泡咖啡的茶壶返回。此HTTP状态在某些网站（包括Google.com）中用作复活节彩蛋。

是的，我可以确认，我已经看到HTTP 418从真实的生产服务器返回。它确实存在。

是的，它是“真实的”代码，因为它实际上是由Internet工程任务组作为正式RFC发布的，但是该RFC是4月1日发布的，这是愚人节的玩笑（与其余的Hyper Text Coffee Pot Control一起）协议），而非合法实施。这就是为什么大多数网站都将其用作复活节彩蛋，但要避免使用它的原因。正如此评论所指出的，通常会有更合适的状态，例如400（错误请求）。话虽这么说，多亏了IT社区，它现在是保留的代码，所以不要指望它会很快出现在任何地方。

值得注意的是，根据Larry Masinter（由Wikipedia声称该RFC的作者）所说，所讨论的HTTP扩展确实确实具有（讽刺的）目的：“它标识了不当扩展HTTP的许多方式。”

我认为将418视为保留的代码较为安全，该代码曾经有一半-官方含义，但现在正式“未分配”。

我认为，从历史上看，现在对这些代码的想法有所不同。今天，这听起来毫无意义和可笑。可能不是吗？

换句话说，我将避免使用此代码。