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

Muh*_*eed 18 http http-status-codes request-cancelling cancellation

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

nba*_*ari 19

为了保持一致,我建议400 Bad Request现在,如果您的后端应用程序能够识别客户端何时断开连接,或者您拒绝或关闭连接,可能您可以返回Nginx的非标准代码499或444.

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

  • 444无响应 用于指示服务器未向客户端返回任何信息并关闭连接.

  • ** 204 No Content **:`服务器成功处理了请求,没有返回任何内容。`似乎也非常符合OPs主题。 (3认同)
  • 没有内容不适合超时。204 表示服务器端可能发生某些变化,例如实体已更新 (2认同)

Dam*_*ver 11

HTTP(1.0/1.1)没有取消请求的方法.如果客户端不再需要响应,那么客户端可以执行的操作就是关闭连接并希望服务器包含优化以停止处理无法再传递的响应.由于连接现在已关闭,因此实际上无法将响应或状态代码传递给客户端,因此您"返回"的任何代码仅供您自己满意.我个人会选择4xx范围1中的东西,因为"故障" - 你不能再提供响应的原因 - 是由于客户端.

HTTP 2.0确实允许端点发出END_STREAMRST_STREAM指示他们不再对一个流感兴趣而不会拆除整个连接.但是,它们只是意味着忽略任何进一步HEADERSDATA在该流上发送,因此即使您理论上可以提供状态代码,客户端仍然会完全忽略它.


1可能400本身,因为我无法确定一个看似完全合适的更具体的错误.

  • @TheChetan:这是为了审查,而不是异步取消。 (2认同)

DaS*_*rer 6

确实没什么可做的。引用RFC 7230,第 6.5 节

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

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

  • 虽然客户端不会收到此状态代码,但您的日志记录/指标收集应该_并且在很多情况下,在弄清楚如何使服务/服务器变得更好时,知道由于客户端取消而导致响应未完成非常重要。 (19认同)

Dav*_*ing 5

只有几个合理的选择(当然除了 500):

  1. 202 接受

    你还没有完成处理,你永远不会。

    这仅适用于在您的应用程序域中,原始请求者“期望”并非所有请求都将得到满足的情况。

  2. 409 冲突

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

    这只是微不足道的理由:您的情况不涉及一位客户根据过时信息提出请求,因为取消尚未发生。

  3. 503服务不可用

    对于这一请求,该服务实际上不可用(因为它已被取消!)。

“将错误报告为错误”的一般论点支持 409 或 503。因此默认情况下为503