验证码的HTTP状态码

41
有时候(当资源被请求过于频繁)我会用验证码拦截(HTML)资源的展示。拦截不会产生任何重定向。这都发生在同一个URI上。
现在我想知道哪个HTTP状态码最适合这些要求:
- 它应该符合语义。 - Google应该明白这种拦截是一种临时情况,不应影响其索引中现有的资源。 - 网页浏览器将显示带有验证码的响应主体。
这些是我目前确定的候选项: 409冲突 请求无法完成,因为与资源的当前状态存在冲突。此代码仅允许在预期用户可能能够解决冲突并重新提交请求的情况下使用。响应正文应包含足够的信息,以便用户识别冲突的来源。
这听起来很完美。冲突状态来自那些请求资源过于频繁的客户端。响应还包括足够的信息来识别冲突的来源并解决它。

503服务不可用

由于服务器暂时超载,当前无法处理请求。这意味着这是一个临时状态。如果已知延迟时间,可以在Retry-After头中指示。

这听起来比较合适。我甚至可能知道延迟的时间并提供这样的头文件。但是,我错过了用户可以解决问题的重点。此外,范围太广(超载服务器与超载资源)。

3个回答

18

3
我认为401会是一个合适的响应。验证码是一种身份验证形式,旨在验证用户代理的控制者是人类。我正在研究在WWW-Authenticate头中提供什么,但我将从以下内容开始: WWW-Authenticate: X-Captcha - John
401表示存在一个定义的身份验证方案。不要杜撰一个方案只是为了使用401。 - Julian Reschke
2
RFC要求提出挑战,但并不要求所有用户代理都理解挑战。该示例是针对标准中不存在的方案的挑战,因此我认为,如果应用程序能够利用该方案,引入它是合理的。当我阅读429规范时,似乎客户端应该停止发出请求。这不是期望的行为:我们希望客户端在身份验证后重新提交请求。Youtube在有太多请求时使用402,但该状态现已保留供将来使用。 - John
@JulianReschke 您可以将提交的reCAPTCHA解决方案令牌视为身份验证,以便获得对某些资源的授权。拥有 Authorization: reCAPTCHA <token> 请求和 WWW-Authenticate: reCAPTCHA 响应是没有问题的,您可以自己编写并且只有您的服务器知道。您不必将其注册到某些标准机构。 - Константин Ван
需要添加到此命名空间的值需要经过IETF审查(参见[RFC5226]第4.1节)。 - Julian Reschke
显示剩余4条评论

3

对于我来说,422 在这种情况下有一定的准确性:

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


1

FWIW我正在使用498。

维基百科: 代码498表示令牌过期或无效。

498无效令牌(Esri) 由ArcGIS for Server返回。代码498表示令牌过期或无效。


1
这不是标准代码。 - Evert

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接