418“I'm a teapot"真的是HTTP响应代码吗?

小开

HTTP响应代码418最初在RFC 2324(“超文本咖啡壶控制协议(HTCPCP/1.0)”)和RFC 7168(“茶外排设备超文本咖啡壶控制协议(HTCPCP- Tea)”)协议中定义。

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

小开

我使用这个代码。我有nginx反向代理请求到两个不同的HTTP服务器。一个处理未经身份验证的用户的请求，另一个处理经过身份验证的用户的请求。在这个特殊情况下的问题是，第一个服务器是决定用户是否经过身份验证的服务器。请不要问为什么。

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

这是在HTCPCP代码418的精神，因为如果你试图用茶壶冲泡，适当的反应是“我不是那种可以处理这个请求的人，但可能有其他人。”．．换句话说，“我是茶壶”。找一个咖啡机。(第二个服务员是咖啡机)。

最终，虽然418在RFC 7231中没有显式定义，但它仍然被4xx (Client Error)的保护伞所覆盖。

6. 响应状态码

4xx(客户端错误):请求包含错误的语法或无法实现

6.5. 客户端错误4xx

状态码的4xx (Client Error)类表示客户端错误似乎错了。除非响应HEAD请求，否则服务器应该发送一个包含解释的表示错误的情况，以及它是暂时的还是永久的条件。这些状态码适用于任何请求方法。用户代理应该向用户显示任何包含的表示

小开

我认为把418当作一个曾经有半官方含义，但现在正式“未分配”的保留代码是更安全的。

我认为，历史上对这些代码的看法与现在有所不同。这在今天听起来毫无意义，也很有趣;也许不是?

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

小开

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

小开

是的，这是一个“真实的”;在某种意义上，它是由互联网工程任务组rfc - 2324作为官方RFC的一部分发布的。然而，由于RFC是在4月1日发布的，并且是一个愚人节玩笑(与超文本咖啡壶控制协议的其余部分一起)，而不是为了合法的实现，所以它不是一个“严肃的”RFC。典型意义上的代码*。这就是为什么大多数网站使用它作为复活节彩蛋，但在其他方面都避免使用它。正如这样的评论中的wizulus所指出的，通常有更合适的状态，如400(坏请求)。尽管它具有讽刺的性质，但它现在是一个保留代码(大概是成为一个流行的工程meme的结果)，所以不要指望它很快就会消失。

*根据RFC的作者Larry M Masinter的说法，这个HTTP扩展实际上有一个严肃但讽刺的目的:它指出了HTTP被不恰当地扩展的许多方式。

小开

你真的不应该用超文本茶壶控制协议(HTTCP)来煮咖啡。这是HTCPCP(超文本咖啡壶控制协议)的工作。

小开

我真的在用它。在我的项目中，我们有一个后端和一个前端，如果我正在开发一个新的API，我用418来表示“坏的请求，不应该在前端”。它们现在会在我们的错误报告工具中触发一个严重级别为“警告”的事件，而标准400只会在“信息”级别触发。

我不想使用500，因为它是一个错误的调用者，我不认为它是一个常规的400，因为我们有很多情况下，后端是处理验证和400不是一个bug。我们本可以使用501，但它在4xx中，因为它是一个请求错误。