有时候(当资源被请求过于频繁)我会用验证码拦截(HTML)资源的展示。拦截不会产生任何重定向。这都发生在同一个URI上。
现在我想知道哪个HTTP状态码最适合这些要求:
- 它应该符合语义。 - Google应该明白这种拦截是一种临时情况,不应影响其索引中现有的资源。 - 网页浏览器将显示带有验证码的响应主体。
这些是我目前确定的候选项: 409冲突 请求无法完成,因为与资源的当前状态存在冲突。此代码仅允许在预期用户可能能够解决冲突并重新提交请求的情况下使用。响应正文应包含足够的信息,以便用户识别冲突的来源。
这听起来很完美。冲突状态来自那些请求资源过于频繁的客户端。响应还包括足够的信息来识别冲突的来源并解决它。
现在我想知道哪个HTTP状态码最适合这些要求:
- 它应该符合语义。 - Google应该明白这种拦截是一种临时情况,不应影响其索引中现有的资源。 - 网页浏览器将显示带有验证码的响应主体。
这些是我目前确定的候选项: 409冲突 请求无法完成,因为与资源的当前状态存在冲突。此代码仅允许在预期用户可能能够解决冲突并重新提交请求的情况下使用。响应正文应包含足够的信息,以便用户识别冲突的来源。
这听起来很完美。冲突状态来自那些请求资源过于频繁的客户端。响应还包括足够的信息来识别冲突的来源并解决它。
503服务不可用
由于服务器暂时超载,当前无法处理请求。这意味着这是一个临时状态。如果已知延迟时间,可以在Retry-After头中指示。
这听起来比较合适。我甚至可能知道延迟的时间并提供这样的头文件。但是,我错过了用户可以解决问题的重点。此外,范围太广(超载服务器与超载资源)。
Authorization: reCAPTCHA <token>
请求和WWW-Authenticate: reCAPTCHA
响应是没有问题的,您可以自己编写并且只有您的服务器知道。您不必将其注册到某些标准机构。 - Константин Ван