HTTP 状态 202 - 如何提供有关异步请求完成的信息？答案

【问题标题】：HTTP Status 202 - how to provide information about async request completion?HTTP 状态 202 - 如何提供有关异步请求完成的信息？
【发布时间】：2013-01-27 18:50:21
【问题描述】：

当服务器为异步请求返回 202 - Accepted 状态码时，估计请求完成的适当方法是什么？

来自HTTP spec（斜体由我添加）：

202 接受

请求已被接受处理，但处理尚未完成。 [...]

与此响应一起返回的实体应包含请求当前状态的指示以及指向状态监视器的指针或用户可以预期何时完成请求的一些估计。 p>

以下是一些想法：

我看过max-age指令，但使用它会滥用Cache-Control？
在响应正文中返回预期的等待时间？
添加特定于应用程序的X- 响应标头，但X-headers 在RFC 6648 中已弃用？
添加（非X-）特定响应标头？如果是这样，它应该如何命名？ SO 问题Custom HTTP headers : naming conventions 给出了一些想法，但在弃用之后，它只回答了 HTTP 标头的格式，而不是它们应该如何命名。
其他建议？

【问题讨论】：

标签： rest http-headers http-status-codes

【解决方案1】：

绝对不要为此滥用现有的 HTTP 标头。由于它是您自己的服务器，因此您可以定义响应的外观。您可以（并且应该）选择最适合此信息的预期接收者的任何响应，并在响应正文中返回实际信息。

例如，如果您只对显示人类可读的消息感兴趣，那么您可以返回 text/plain 说“您的请求可能会在接下来的 30 分钟内得到处理。”。

另一方面，您可能希望全部采用 REST 方式并返回 application/json，可能格式如下（我完全是当场编造的）：

{
  "status": "pending",
  "completion": {
    "estimate": "Thu Sep 08 2011 12:00:00 GMT-0400",
    "rejected-after": "Fri Sep 09 2011 12:00:00 GMT-0400",
  },
  "tracking": {
    "url": "http://server/status?id=myUniqueId"
  }
}

【讨论】：

【解决方案2】：

您可以使用Location 标头来指定状态监视器的URL。当前状态和估计值之类的内容可以放在自定义标头（除了您自己的软件之外没有人会使用）或响应正文（至少 Web 浏览器会显示给用户）。

【讨论】：

谢谢，我忘记了 Location 标头。最有可能的是，我们将使用自定义响应正文。
碰巧的是，实际上不能在 PHP 中使用带有 HTTP 202 的 Location 标头，因为它根据 RFC 2616 强制执行特殊语义，参见。 php.net/manual/en/function.header.php "第二种特殊情况是"Location:" 标头。它不仅将此标头发送回浏览器，而且还会向浏览器返回一个REDIRECT (302) 状态码，除非是201 或3xx 状态码已经设置好了。”
@JosipRodin RFC 2616 并未限制 Location 在 202（或任何其他响应）中使用，它仅定义了 Location 在 201/3xx 的情况下所指的内容。所以这是一个 PHP 语义（或错误，取决于你如何看待它），而不是 HTTP 语义。
@RemyLebeau 告诉 PHP 开发人员...这是先前试图争论这一点的尝试：bugs.php.net/bug.php?id=70273，这是我最近的请求，只是为了让它告诉人们它在做什么：bugs.php.net/bug.php?id=74535
@JosipRodin：“实际上不能在 PHP 中使用带有 HTTP 202 的 Location 标头” - jeff 在 2015 年 8 月对 bugs.php.net/bug.php?id=70273 的评论-17 16:35 UTC 展示了如何在 PHP 中实现此目的的几种方法。

【解决方案3】：

虽然没有明确提及 202 - Accepted 响应代码，但 Retry-After 标头似乎是一个合适的选项。来自documentation：

Retry-After response-header 字段可用于 [...] 来指示服务预计对请求客户端不可用的时间。

【讨论】：

鉴于该值应该是“整数秒数（十进制）”，如果我们想要更好的分辨率，X-Retry-After 标头是否具有例如值毫秒更合适？
@JosipRodin 我建议使用Retry-After: 0 而不是发明自定义标头，因为当客户端收到响应时，无论如何都会过去几毫秒，他们可以立即重试。在异步操作的情况下，Retry-After: 0 似乎在说“结果尚未准备好，但请随时再次询问（只要您愿意）。”
@Gili 但如果我不想让他们随时问怎么办？例如，如果大部分客户端相距 150 毫秒，即每秒 6 个请求，我可能想到每秒只有 2 个请求。
@JosipRodin 这个标头只不过是给客户的一个建议。客户可以（并且确实）忽略它。这个标头是服务器的说法：“如果你愿意，你可以更快地重复请求，但我认为在接下来的 X 秒内响应不会改变”。客户会做最适合他们的事情，因此您永远无法获得您想要的控制水平。
根据文档和用例，Retry-After 只能与503、429 和301 一起使用。不建议 202 使用。 developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After RFC w3.org/Protocols/rfc2616/rfc2616-sec10.html 提到：“与此响应一起返回的实体应该包括请求当前状态的指示以及指向状态监视器的指针或用户可以期望何时完成请求的一些估计。”