在HTTP响应标头之后重试 - 它会影响任何事情吗？

如果由于临时过载而我想礼貌地拒绝网站上的服务,则HTTP响应503服务不可用似乎是合适的.该规范提到使用503 发送Retry-after标头.

有什么意义吗？Retry-after会影响任何事情吗？浏览器是否关注它？

1> Clint Pachl..：

---

Retry-After标头的当前状态

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

首先,RFC 2616,第14.37节重试 - 后状态:

Retry-After响应头字段可以与503(服务不可用)响应一起使用,以指示服务预期对请求客户端不可用的时间.

...

其使用的两个例子是

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

在后一个例子中,延迟是2分钟.

支持客户端和服务器软件

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

镀铬/铬

2012年11月22日的代码提交,其中包含日志消息: 添加了检测超时和Retry-After HTTP标头的使用.

火狐浏览器

2012年3月27日的代码提交日志信息:实现5xxs的处理,X-Weave-Backoff,Retry-After.此外,Mercurial存储库中还有其他三个Retry-After标头.

最初在2004年1月6日提交了一个错误,忽略了使用HTTP 503响应发送的标题Retry-After.

Googlebot的

有关处理网站停机时间的Google网站管理员中心博客文章提到可以使用Retry-After标头来确定何时重新抓取网址.

Bingbot/MSNBot会

找不到任何官方的Retry-After支持文档.但是,随机论坛中有一些提及在503响应中使用此标题来限制微软的机器人.

Nginx的

该add_header指令规定:

如果响应代码等于200,201,204,206,301,302,303,304或307,则将指定字段添加到响应头.

因此,要使用版本为503响应添加Retry-After标头:

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

1.7.5及更高版本,将always参数附加到add_header指令.

阿帕奇

与Nginx不同,Apache 头文档没有表明它不能在503响应上发送Retry-After头.但是,关于非2xx响应,文档说明:

向本地生成的非成功(非2xx)响应添加标头,例如重定向,在这种情况下,仅在最终响应中使用对应于always的表.

这是一个SO答案,设置一个Retry-After标头,其中包含503响应的始终条件,正如文档建议的那样.

AskApache文章提供了其他配置示例,说明如何使用带有Retry-After标头的503响应来指示搜索引擎返回.

客户端测试

我写了一个Ruby服务器,它只返回一个503响应,Retry-After标头设置为10秒,一个包含随机数的主体.

require 'sinatra'

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

我访问它:

OpenBSD 5.8使用Chromium 44,Firefox-ESR 38和Seamonkey 2.33,

Mac OSX 10.7.5使用Chrome 47和Safari 6.1,

Windows 10使用Chrome 48,Firefox 41和Edge 25.

我希望这些浏览器在10秒后自动刷新URL并显示一个新的随机数.但是,即使几分钟后,所有浏览器都没有重试.我尝试了更短和更长的Retry-After时段以及相同的结果.服务器访问日志确认没有从任何这些浏览器重试.

此外,在Retry-After期间之前的"软"刷新立即重新获取URL.因此,Retry-After标头不能用于限制"刷新快乐"用户.我之所以提到这一点是因为我在一些论坛中看到这个标题可以用来阻止不耐烦的用户锤击你的网站.

作为旁注,"软"刷新在超时期限之前没有动作似乎是合乎逻辑的,但"硬"或高速缓存旁路刷新会忽略任何超时并立即重新获取URL.

结论

在客户端和服务器上,对Retry-After标头的支持似乎仍然有点粗略.尽管如此,如果配置不困难,最好为503响应设置重试超时.

即使Googlebot是唯一支持标头并在超时期限后实际重试的客户端,它也可能会使您的网页无法取消索引 - 而不是404,500,502或504响应.

---

此外,在使用某些API(例如Google Cloud Messaging)时,必须遵守此标头:https://developer.android.com/google/gcm/http.html

2> cHao..：

---

据我所知,没有浏览器会关注Retry-after标题.代理和缓存可能,但是

显然,一些浏览器现在包含一定程度的支持Retry-After(尽管支持仍然是最好的).我并不完全相信在浏览器中这样做的好处; 通常,缓存失败被认为是个坏主意.但如果您知道何时再次接受请求,告诉客户不会受到伤害.(如果你比预期更早回来,那么任何真正尊重标题的程序都应该假设 - 并报告 - 该网站仍在关闭.)

最明显的好处是,似乎Googlebot(以及可能的其他蜘蛛)会关注标题,如果它存在,这可以防止它在一段时间内对页面进行非索引编制.

尽管如此......如果添加它是微不足道的,并且您可以对服务何时可用提出合理准确的估计,那就去吧.不过,我不建议你不要这样做.无论如何它只是建议,并且在那里错误的时间可能导致更多的问题,而不是包括标题.

---

这个答案有点过时了.请参见http://stackoverflow.com/a/23863426/825364

3> dotancohen..：

---

我认为这是一个鸡蛋和鸡蛋的问题:没有浏览器目前实施Retry-after,因为没有网站打扰.在我看来,继续将其作为服务发送给用户.如果他们选择的Web浏览器没有实现它,那就是他们的浏览器只是没有给他们提供有用的信息.你做到了!

在寻求实现具有多个竞争实现的标准时,我总是试图遵循标准而不关注不同的实现(除非我特意尝试模拟实现,例如cURLing但是将我的标头伪装成看起来像网页浏览器).否则,我们最终会达到事实上的标准,如果你还记得你不想要的IE-dominence日子!