已取消请求的正确 HTTP 状态代码是什么

Question

当客户端在发出 HTTP 请求时取消 TCP 连接时，我想停止在服务器上执行任何工作并返回空响应。这样的响应应该返回什么 HTTP 状态代码？

Answer 1

为了保持一致，我建议

400 Bad Request

现在如果你的后端应用程序能够识别客户端何时断开连接，或者如果你拒绝或关闭连接，你可能可以返回Nginx的非标准代码499或444。

• 499 客户端关闭请求 当客户端在服务器发送响应之前关闭请求时使用。

• 444 无回应 用于表示服务器端没有返回任何信息给客户端，关闭了连接。

Answer 2

HTTP (1.0/1.1) 没有办法取消请求。如果客户端不再需要响应，它所能做的就是关闭连接，并希望服务器包含优化以停止处理无法再传递的响应。由于连接现在已关闭，因此实际上无法将任何响应或状态代码传递给客户端，因此您“返回”的任何代码都只是为了您自己满意。我个人会选择 4xx 范围内的内容¹，因为“故障”（您无法再提供响应的原因）是由客户造成的。

HTTP 2.0 确实允许端点发出

END_STREAM

或

RST_STREAM

来指示它们不再对某个流感兴趣，而无需断开整个连接。然而，它们只是忽略在该流上发送的任何进一步的

HEADERS

或

DATA

，因此即使理论上您可以传递状态代码，客户端仍然会完全忽略它。

---

¹可能是 400 本身，因为我无法识别似乎完全合适的更具体的错误。

Answer 3

只有几个看似合理的选择（当然，除了 500 个）：

1. 202 已接受

   您还没有完成处理，而且永远也不会完成。

   仅当在您的应用程序域中原始请求者“期望”并非所有请求都会得到满足时，这才是合适的。

2. 409冲突

   …在提出和取消请求之间。

   这只是很弱的理由：您的情况不涉及一位客户根据过时的信息提出请求，因为取消尚未发生。

3. 503 服务不可用

   该服务实际上无法用于这一请求（因为它已被取消！）。

“将错误报告为错误”的一般论点倾向于 409 或 503。所以 503 它是默认值。

Answer 4

确实没什么可做的。引用自

RFC 7230，第 6.5 节：

客户端、服务器或代理可以随时关闭传输连接。

这发生在 TCP 级别，而不是 HTTP 级别。只需停止处理连接即可。状态代码在这里没有什么意义，因为不完整/损坏的请求的意图仅仅是猜测。此外，也没有办法将其传输给客户。

Answer 5

我想知道和OP一样的事情。老实说，这个问题没有正确的答案，因为没有任何方式对其进行监管。取消的请求永远不会到达客户端，但如果您的服务器设置了一些更复杂的代理路由，这样的响应可能会在日志中可见，所以我将选择一些容易找到的内容，如

418 I'm a teapot

Answer 6

我想这永远是主观的，但我认为有意义但我认为尚未提及的另一个选择是

408 Request Timeout

。来自

https://http.dev/408:

当收到 408 Request Timeout 错误消息时，表示客户端已经发起了请求，但由于某种原因没有完整发送。出现这种情况的原因可能是互联网连接速度非常慢或已断开。响应将包含 Connection 标头，指定它已关闭。