【问题标题】：HTTP Status Code for Captcha验证码的 HTTP 状态码
【发布时间】：2014-12-20 06:21:24
【问题描述】：

有时（当资源被请求太频繁时）我会拦截带有验证码的 (HTML) 资源的呈现。拦截不会产生任何重定向。它发生在同一个 URI 上。

我现在想知道哪种 HTTP 状态代码最适合这些要求：

这些是我目前确定的候选人：

409 Conflict

由于与资源的当前状态冲突，请求无法完成。仅在预期用户可能能够解决冲突并重新提交请求的情况下才允许使用此代码。响应正文应该包含足够的信息，以便用户识别冲突的来源。

这听起来很完美。冲突状态来自那些过于频繁地请求资源的客户端。响应还包括足够的信息来确定冲突的根源并解决它。

503 Service Unavailable

由于服务器临时过载 [...]，服务器当前无法处理请求。这意味着这是一种暂时的情况[…]。如果已知，延迟的长度可以在 Retry-After 标头中指示。

这听起来很合适。我什至可能知道延迟的长度并提供这样的标题。但是我在这里错过了用户可以解决问题的观点。此外，范围太广（服务器过载与资源过载）。

【问题讨论】：

【解决方案1】：

对我来说 422 对于这种情况有点准确：

响应状态码表示服务器理解内容请求实体的类型，请求实体的语法是正确，但无法处理包含的指令。

【讨论】：

【解决方案2】：

您可能需要考虑在https://www.rfc-editor.org/rfc/rfc6585#section-4 中定义的状态码 429。

【讨论】：

我认为 401 将是一个适当的响应。 Captcha 是一种身份验证形式，旨在验证用户代理控制器的人性。我正在研究在 WWW-Authenticate 标头中提供什么，但我将从 WWW-Authenticate: X-Captcha
嗯，401 意味着存在已定义的身份验证方案。不要为了能够使用 401 而制定方案。
RFC 要求提出质询，但并不要求所有用户代理都理解质询。该示例对标准中不存在的方案是一个挑战，因此这使我相信，如果应用程序能够使用该方案，那么引入它是合理的。当我阅读 429 的规范时，似乎客户端应该停止发出请求。这不是期望的行为：我们希望客户端在验证后重新提交请求。当请求过多时，Youtube 使用 402，但该状态现在保留以供将来使用。
@JulianReschke 为什么不自定义auth-scheme呢？ RFC 7235 说“好的”。
@КонстантинВан 你能更具体一点吗？是的，您可以定义新的身份验证方案，但这需要将其写下来并注册。