当发出HTTP请求时客户端取消TCP连接时,我想停止在服务器上做任何工作并返回空响应。这样的响应应返回什么HTTP状态代码?
答案 0 :(得分:15)
为了保持一致,我建议400 Bad Request
现在如果您的后端应用程序能够识别客户端何时断开连接,或者您拒绝或关闭连接,可能您可以返回Nginx'非标准代码499或444。
499客户关闭请求 在客户端在服务器发送响应之前关闭请求时使用。
444无响应 用于指示服务器未向客户端返回任何信息并关闭连接。
答案 1 :(得分:9)
HTTP(1.0 / 1.1)没有取消请求的方法。如果客户端不再需要响应,那么客户端可以执行的操作就是关闭连接并希望服务器包含优化以停止处理无法再传递的响应。由于连接现已关闭,因此实际上无法将响应或状态代码传递给客户端,因此您返回的任何代码都会被拒绝。只是为了你自己的满意。我个人会选择4xx范围内的东西 1 因为"故障" - 您无法再提供回复的原因 - 取决于客户。
HTTP 2.0确实允许端点发出END_STREAM
或RST_STREAM
来表示他们不再对一个流感兴趣而不会拆除整个连接。但是,它们意味着要忽略在该流上发送的任何其他HEADERS
或DATA
,因此即使您理论上可以提供状态代码,客户端仍然会完全忽略它。
1 可能400本身,因为我无法确定一个看似完全合适的更具体的错误。
答案 2 :(得分:1)
只有几个合理的选择(当然除了500):
202接受
你还没有完成处理,你永远也不会。
只有在您的申请域中,原始请求者"期望"并非所有要求都会得到满足。
409冲突
...在制作和取消请求之间。
这只是虚弱的理由:您的情况并不涉及一个客户根据过时的信息提出请求,因为取消尚未发生。
503服务不可用
该服务实际上不适用于这一个请求(因为它被取消了!)。
"report an error as an error"的一般论点偏好409或503.所以 503 默认情况下。
答案 3 :(得分:1)
真的没什么可做的。引自RFC 7230, section 6.5:
客户端,服务器或代理可以随时关闭传输连接。
这发生在TCP-而不是HTTP级别。只需停止处理连接即可。状态代码在这里没什么意义,因为不完整/破坏请求的意图仅仅是推测。此外,没有办法将其传送给客户。