什么是取消请求的正确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级别。 只需停止处理连接即可。 状态代码在这里没什么意义，因为不完整/破坏请求的意图仅仅是推测。 此外，没有办法将其运送到客户端。