服务器在收到整个请求之前发送 HTTP 响应是否可以接受？答案

【问题标题】：Is it acceptable for a server to send a HTTP response before the entire request has been received?服务器在收到整个请求之前发送 HTTP 响应是否可以接受？
【发布时间】：2012-12-24 10:21:02
【问题描述】：

考虑一个大的 HTTP 请求：

POST /upload HTTP/1.1
Content-Type: multipart/form-data
Content-Length: 1048576

...

客户端现在开始上传 1 兆字节的数据，这可能需要一段时间。但是，服务器确定需要 HTTP 授权，因此它决定以HTTP 401 Unauthorized 响应。

服务器必须等到它收到整个请求（IE、标头 + CRLF CRLF + Content-Length 字节）后才能响应？

实际上，这种行为会破坏任何浏览器吗？浏览器是否会继续上传文件，或者如果收到“过早”响应，它们会停止传输吗？

更重要的是，在这种情况下，他们是否能够成功验证并再次开始上传（使用凭据），还是像这样切断上传不可靠？

【问题讨论】：

那么你找到答案了吗？
@DonghwanKim：是的，HTTP 服务器在收到整个请求之前发送响应是有效的。不幸的是，no browser will see the early response and stop sending the request，它本身可能违反了 RFC 2616 § 8.2.2。
谢谢，很高兴知道

标签： http

【解决方案1】：

查看定义协议的 RFC 2616，在第 8.2.2 节“监控连接以获取错误状态消息”中指出

发送消息正文的 HTTP/1.1（或更高版本）客户端应在传输请求时监视网络连接的错误状态。如果客户端看到错误状态，它应该立即停止传输正文。

所以我想说使用你可以跳转到发送 401 错误。然后查看 10.4.2 401 Unauthorized

请求需要用户身份验证。响应必须包含一个 WWW-Authenticate 头字段（第 14.47 节），其中包含适用于所请求资源的质询。客户端可以使用合适的 Authorization 头域重复请求

声明客户端可以使用合适的凭据重试。

我还没有进行任何实验来了解浏览器的实际性能。

【讨论】：

我在testing this behavior 解决了一个稍微不同的问题，但答案并不漂亮。所有浏览器在完成发送请求之前都不会处理早期响应。
好的，所以 RFC 声明客户端应该“停止传输正文”。但是服务器不知道下一个请求从哪里开始，所以客户端“停止传输”就意味着断开连接，因为 keep-alive 需要知道请求的结束。
@DDS 这个答案引出了另一个问题。浏览器不能截断并替换为提前终止请求吗？
似乎 Apache HttpClient for Java 无法在服务器不读取整个请求正文的情况下存活下来，这很可悲:(我们遇到了这个问题，当不使用抢先式 HTTP 基本身份验证时并且服务器已经从标头中看到该请求不能被允许并立即发送 HTTP 401。我知道 curl 和 wget 可以在这种情况下幸存下来。我的观点是，所有客户端都应该能够处理这个问题，因为这很重要服务器可以防止恶意客户端发送大量请求而造成的拒绝服务攻击。
我遇到了同样的问题。所有浏览器都看不到来自服务器的实际响应。他们传输整个事情，并将连接视为关闭并重试。如果浏览器不固定，则服务器必须进行补偿，并且在接收所有发送的有效载荷时会受到资源的影响。如果这样做了，它将产生 DDOS 攻击的可能性，该攻击在响应之前等待数据上传。不好。浏览器需要支持规范。