HTTP POST响应时间长

我有一个web应用程序，在后端有一些相当强大的数据处理。当前的工作流示例是：

用户发布表单

服务器接收表单，开始处理

2-4分钟过去

服务器响应

我问这个问题的原因是，最初用户端的一个web代理在2分钟后杀死了空闲的帖子。我想得越多，这似乎越是合理的违约

---

这就留下了一个问题，我应该增加超时时间而不是修复问题吗？还是这种做法不好？目前为2-4分钟，但很容易延长。应用程序是否应该以某种方式响应，而不仅仅是保持连接打开？如果是这样的话，除了完全重新设计用户界面，使其成为异步提交/稍后检查还有哪些选项？

一般来说，如果我要提交一个表单，并且需要那么长的时间，我会认为可能出了问题并再次尝试提交。我认为你应该收集数据，给用户一些成功的信息。然后创建另一个页面，允许他们检查处理的状态（如果用户需要从该处理中获得结果）。

是的，我完全同意这一点，但反驳的论点是，这主要是一个内部应用程序，用户经过培训。为了证明重新设计的合理性，我认为这需要是一个技术原因，而不是用户体验原因。如果用户关闭浏览器或意外重新提交，会发生什么？它一次处理多个提交的情况如何？当这个过程开始需要10分钟才能完成时，会不会发生反抗？