如何在处理标头后立即重定向 HTTP POST 请求？答案

【问题标题】：How can I redirect a HTTP POST request immediately after the headers are processed?如何在处理标头后立即重定向 HTTP POST 请求？
【发布时间】：2010-08-07 10:30:56
【问题描述】：

在 Windows CE 上，我目前处于从头开始实现一个简单的 Web 服务器的情况。该服务器的主要用途将是一对一的 USB RNDIS 连接。服务器由设备上运行的托管应用程序托管。

因此，我们将 POST 请求处理与交付的网页紧密集成在一起。不是处理完整的请求并存储太大的 POST 数据，而是通过接收其标头及其内容流来通知当前页面（由请求标识）任何 POST 多部分。此解决方案有效且大放异彩，每个人都很高兴。

现在，问题来了：应用程序 Web 界面中的一个页面允许上传软件更新，其大小可以是 11 到 40 MB。在处理这个 POST 请求时，我们有各种验证步骤，比如基于会话 cookie 的权限系统。由于所述会话 cookie，我们知道是否允许客户端在处理完所有标头后立即上传软件更新。有什么方法可以避免必须读入（并丢弃）所有 POST 内容，以便用户立即获得反馈？

我们的第一个想法是在标头处理后返回正确的错误消息响应，然后关闭连接，但浏览器（似乎是正确的）抱怨对等端过早重置。

【问题讨论】：

标签： http windows-ce http-post http-redirect

【解决方案1】：

浏览器会希望进行完整的传输。为用户提供更好的响应能力的解决方法可能是在页面上使用 AJAX 调用 - 因此页面应该进行 AJAX 调用以异步将实际上传发布到另一个页面，而不是页面接收数据。我自己，我会用 jQuery 来做这件事，但是你可以在没有任何框架的情况下将脚本放在一起相当容易地做到这一点。

【讨论】：

很遗憾 :-( 感谢您的澄清

【解决方案2】：

自从我最近仔细研究了相关的 RFC：

HTTP 1.1 为这种场景添加了一个额外的请求标头

Expect: 100-Continue

这告诉服务器检查请求标头并返回“好的，您现在可以开始向我发送实际内容”或“抱歉，无论您打算向我发布什么，我都无法处理它” - 响应（有关更精确的技术细节，请参阅the HTTP 1.1 RFC）

但是，这并不能解决我的情况，因为典型的用户代理（Firefox 3.6、IE 8）在发布 multipart/form-data 时不使用此功能。然而，手工开发的助手应用程序可能想要使用此功能。

【讨论】：