Captcha的HTTP状态代码

Mar*_*sch 23 captcha http http-status-codes http-status-code-503 http-status-code-409

有时(经常请求资源时)我正在拦截带有验证码的(HTML)资源的呈现.拦截不会产生任何重定向.它发生在同一个URI上.

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

  • 它应该在语义上适合.

  • 谷歌应该明白这个拦截是一个临时条件,不应该影响其索引中的现有资源.

  • Web浏览器将显示带有验证码的响应正文.

这些是我到目前为止确定的候选人:

409冲突

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

这听起来很完美.冲突状态来自那些经常请求资源的客户端.响应还包括足够的信息来识别冲突的根源并解决冲突.

503服务不可用

由于服务器临时过载,服务器当前无法处理请求.这意味着这是一个暂时的条件[...].如果已知,则可以在Retry-After报头中指示延迟的长度.

这听起来适度.我甚至可能知道延迟的长度并提供这样的标题.但我在这里错过了用户可以解决问题的重点.此外,范围太广(服务器重载与资源过载).

Jul*_*hke 8

您可能需要考虑在http://tools.ietf.org/html/rfc6585#section-4中定义的状态代码429 .

  • 我在想 401 会是一个合适的回应。Captcha 是一种身份验证形式,旨在验证用户代理控制器的人性。我正在研究在 WWW-Authenticate 标头中提供什么,但我将从 WWW-Authenticate: X-Captcha 开始 (2认同)
  • RFC要求提出挑战,但并不要求所有用户代理都能理解挑战.该示例对于标准中不存在的方案是一个挑战,因此这使我相信如果应用程序能够使用该方案,则引入它是合理的.当我读到429的规格时,似乎客户端应该停止发出请求.这不是所期望的行为:我们希望客户端在身份验证后重新提交请求.当请求太多时,Youtube使用402,但现在保留该状态以供将来使用. (2认同)