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

I use this code. I have nginx reverse-proxying requests to two separate HTTP servers. One handles requests for unauthenticated users, and the second handles requests for authenticated users. The problem in this particular case, is the first server is the one that determines if the user is authenticated. Please don't ask why.

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

So, if the first server determines the user is authenticated, it responds 418 I'm a teapot. NGINX then reroutes the traffic internally to the second server. As far as the browser is concerned, it was a single request.

这是 HTCPCP代码418 的精神，因为如果如果您尝试用茶壶BREW，则适当的响应是我不是那种可以处理该请求的事物，但可能还有其他事物." ..换句话说，我是茶壶.找到咖啡机." (第二台服务器是咖啡机).

This is in the spirit of HTCPCP code 418, because if you attempt to BREW with a teapot, the appropriate response is "I'm not the kind of thing that can handle that request, but there may be others." .. In other words, "I'm a teapot. Find a coffee maker." (the second server being the coffee maker).

最终，虽然未在 RFC 7231 中明确定义418，但实际上是仍然被4xx (Client Error)的保护伞覆盖.

Ultimately, while 418 is not explicitly defined in RFC 7231, it is still covered by the umbrella of 4xx (Client Error).

6.响应状态代码

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

6.5.客户端错误4xx

• 状态代码的4xx(客户端错误)类指示客户端 似乎已经犯了错误.除了回应HEAD要求外， 服务器应该发送一个包含以下内容的解释的表示形式: 错误情况，以及它是临时的还是永久的 健康)状况.这些状态代码适用于任何请求方法. 用户代理应该向用户显示任何包含的表示形式.

• The 4xx (Client Error) class of status code indicates that the client seems to have erred. Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents SHOULD display any included representation to the user.