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

考虑一个大型HTTP请求：

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

...

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

HTTP401unauthorized

进行响应

服务器必须等到收到整个请求（即，headers+CRLF-CRLF+

内容长度

字节）后才能响应吗

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

---

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

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

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

所以我想说，使用你可以跳入一个发送401错误。然后看10.4.2

请求需要用户身份验证。响应必须包括WWW Authenticate标头字段（第14.47节），其中包含适用于请求资源的质询。客户端可以使用适当的授权头字段重复请求

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

---

不过，我还没有进行任何实验来了解浏览器的实际运行情况。

要使之成为可能，您需要使用双线程HTTP客户端或支持异步I/O的HTTP客户端。我找不到任何此类HTTP客户端

但是，您可以设计一个应用层协商协议来实现相同的效果：

在客户端应用程序中，分别启动3个更改消息传递、接收和发送的请求

GET/xxx/connect（使用服务器发送的事件或WebSocket创建任务流程并监视任务状态）

GET/xxx/out？pid=23534（从服务器接收处理结果）

POST/xxx/in？pid=23534（将数据发送到服务器进程）

在服务器应用程序中，使用4个线程

启动新任务流程并立即发布流程状态

获取

流

在流中获取

开始处理

---

你找到答案了吗？@DonghwanKim:是的，HTTP服务器在收到整个请求之前发送响应是有效的。不幸的是，这本身可能违反了RFC 2616§8.2.2。谢谢，很高兴知道我最终遇到了一个稍微不同的问题，答案并不完美。所有浏览器在完成发送请求之前都不会处理早期响应。好的，RFC声明客户端应该“停止发送正文”。但是服务器无法知道下一个请求从何处开始，因此客户端“停止传输”意味着断开连接，因为保持活动状态需要知道请求的结束。@DDS这个答案提出了另一个问题。浏览器不能截断并替换为提前终止请求吗？Apache HttpClient for Java似乎无法在服务器不读取整个请求正文的情况下生存，这是令人遗憾的：（我们遇到了这个问题，当不使用先发制人的HTTP基本身份验证时，服务器已经从头中看到请求不能被允许，并立即发送HTTP 401。我知道curl和wget可以在这种情况下生存。我的意见是，所有客户端都应该能够处理这个问题，因为使之成为可能非常重要为服务器提供保护，以防止恶意客户端发送大请求而可能造成的拒绝服务攻击。我看到了相同的问题。所有浏览器都看不到服务器的实际响应。它们传输整个内容，并将连接视为已关闭，然后重试。如果浏览器未修复，则服务器必须补偿错误d在接收所有发送的有效负载时会受到资源方面的影响。如果这样做，则可能会造成DDOS攻击，在响应之前等待数据上传。不好。浏览器需要支持规范。