http - 在 HTTP 响应 header 之后重试 - 它会影响什么吗？

Question

如果由于临时重载而我想礼貌地拒绝网站上的服务，HTTP 响应 503 Service Unavailable似乎合适。规范提到发送 Retry-after带有 503 的 header 。

有什么意义吗？ Retry-after 会影响什么吗？浏览器会注意它吗？

Answer 1

Retry-After header 的当前状态

自最初发布此问题以来，客户端和服务器中的 Retry-After header 的实现在最近几年发生了一些变化。所以我想我会提供一个更新的答案。

首先，RFC 2616，section 14.37 Retry-After状态:

The Retry-After response-header field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected to be unavailable to the requesting client.

...

Two examples of its use are

  Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
  Retry-After: 120

In the latter example, the delay is 2 minutes.

支持客户端和服务器软件

以下是有关各种软件中的Retry-After header 的代码存储库提交消息、公告和文档。

Chrome / Chrome

2012 年 11 月 22 日的代码提交，日志消息: Added detection timeouts and usage of Retry-After HTTP header .

火狐浏览器

代码提交于 2012 年 3 月 27 日，日志消息:Implement Handling of 5xxs, X-Weave-Backoff, Retry-After .此外，还有 three other mentions of Retry-After header在他们的 Mercurial 存储库中。

一个错误最初于 2004 年 1 月 6 日提交，标题为 Retry-After sent with HTTP 503 response is ignored .

谷歌机器人

一篇关于处理网站停机时间的 Google 网站管理员中心博客文章提到 Retry-After header may be used to determine when to recrawl the URL .

必应机器人/Msnbot

找不到任何正式的 Retry-After 支持文档。但是，在随机论坛中有一些关于在 503 响应中使用此 header 来限制 Microsoft 机器人程序的提及。

Nginx

add_header directive状态:

Adds the specified field to a response header provided that the response code equals 200, 201, 204, 206, 301, 302, 303, 304, or 307.

因此，要使用版本为 503 响应添加 Retry-After header :

• 1.7.4 及更早版本，使用第三方模块，例如 Headers More .

• 1.7.5 及更高版本，将 always 参数附加到 add_header 指令。

Apache

与 Nginx 不同，Apache header documentation没有迹象表明它不能在 503 响应上发送 Retry-After header 。然而，关于非 2xx 响应，文档声明:

adding a header to a locally generated non-success (non-2xx) response, such as a redirect, in which case only the table corresponding to always is used in the ultimate response.

这是一个SO answer正如文档所建议的那样，它为 503 响应设置了具有 always 条件的 Retry-After header 。

AskApache 文章提供了有关如何 instruct search engines to come back 的其他配置示例使用带有 Retry-After header 的 503 响应。

客户端测试

我编写了一个 Ruby 服务器，它只返回一个 503 响应，其中 Retry-After header 设置为 10 秒，主体包含一个随机数。

require 'sinatra'

get '/' do
  headers 'Content-Type' => 'text/plain', 'Retry-After' => '10'
  status 503
  body rand(1000).to_s
end

我访问了它:

• 使用 Chromium 44、Firefox-ESR 38 和 Seamonkey 2.33 的 OpenBSD 5.8，
• 使用 Chrome 47 和 Safari 6.1 的 Mac OSX 10.7.5，
• 使用 Chrome 48、Firefox 41 和 Edge 25 的 Windows 10。

我原以为这些浏览器会在 10 秒后自动刷新 URL 并显示一个新的随机数。但是，所有浏览器都没有重试，即使在几分钟后也是如此。我尝试了更短和更长的 Retry-After 周期，结果相同。服务器访问日志确认这些浏览器中的任何一个都没有重试。

此外，在 Retry-After 期间之前的“软”刷新会立即重新获取 URL。因此 Retry-After header 不能用于限制“刷新快乐”用户。我提到这个是因为我在一些论坛上看到这个标题可以用来阻止不耐烦的用户攻击你的网站。

作为旁注，“软”刷新在超时期限之前不执行任何操作似乎是合乎逻辑的，但“硬”或缓存旁路刷新将忽略任何超时并立即重新获取 URL。

结论

对 Retry-After header 的支持在客户端和服务器上似乎仍然有点粗略。尽管如此，如果不难配置，为 503 响应设置重试超时是个好主意。

即使 Googlebot 是唯一支持 header 并在超时期限后实际重试的客户端，它也可能会阻止您的网页被取消索引——而不是 404、500、502 或 504 响应。