正好 120 秒后 HTTP 504 超时
我有一个在 Amazon EC2 云中运行的服务器应用程序。我从客户端（浏览器）发出 HTTP 请求，将文件上传到服务器，然后服务器处理该文件。如果有大量处理（大文件 ），服务器总是在 120 秒后超时并出现 504 后端继续错误。虽然我收到此错误，但服务器继续处理请求并完成它（通过检查数据库进行验证），但由于超时，我无法在客户端上看到最终结果。
我不知道为什么会发生这种情况。有人遇到过类似的504超时吗？是否有一些不在我控制范围内的中间代理服务器超时？
I have a server application which runs in the Amazon EC2 cloud. From my client (the browser) I make a HTTP request which uploads a file to the server which then processes the file. If there is a lot of processing (large file
), the server always times out with a 504 backend continuation error always exactly after 120 seconds. Though I get this error, the server continues to process the request and completes it (verified by checking the database) but I cannot see the final result on my client because of the timeout.
I am clueless as to why this is happening. Has anyone faced a similar 504 timeout ? Is there some intermediate proxy server not in my control which is timing out ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我也有类似的问题，就我而言，我认为这是由于弹性负载均衡器 (ELB) 和 EC2 实例之间的连接造成的。
对于长期解决方案，我将采用上面 james.garriss 建议的 303 状态响应 + 后端处理。
对于短期解决方案，Amazon 支持人员可能会增加 ELB 超时（请参阅 https://forums.aws.amazon.com/thread.jspa?messageID=491594）。
不幸的是，似乎没有任何方法可以通过 API 或控制台自行更改超时。[更新] AWS 现在允许您通过以下方式更新空闲超时：控制台、CLI 或 .ebextensions 配置。请参阅 http://docs.aws.amazon.com/ ElasticLoadBalancing/latest/DeveloperGuide/config-idle-timeout.html（感谢@Daniel Patz 的更新）
I have a similar problem and in my case I believe it is due to the connection between the Elastic Load Balancer (ELB) and the EC2 instance.
For a long-term solution I will go with the 303 Status response + back-end processing suggested by james.garriss above.
For short-term solution it may be possible for Amazon support to increase the ELB timeout (see their response in https://forums.aws.amazon.com/thread.jspa?messageID=491594).
Unfortunately there doesn't seem to be any way to change the timeout yourself through either API or console.[Update] AWS now does allow you to update the idle timeout either through console, CLI or .ebextensions configuration. See http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/config-idle-timeout.html (thanks @Daniel Patz for the update)
假设返回正确的状态代码，则问题在于中间代理超时。 “服务器在充当网关或代理时，没有收到来自 URI 指定的上游服务器的及时响应。” （http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.5）这很可能表明源服务器存在某种问题（即，需要很长时间来处理您的请求），所以它的响应速度不快。
也许最好的解决方案是重新设计您的服务器应用程序，使其响应“303 See Other”状态代码；然后，一旦服务器完成处理并创建最终结果，您的客户端就可以在稍后的数据点检索数据。
编辑：另一个想法是重新设计您的服务器应用程序，以便在请求实体大小太大时响应“413 请求实体太大”状态代码。这将消除该错误，但如果您的应用程序只能处理“小”文件，它可能会降低您的应用程序的用处。”
其他可能的解决方案：
Assuming that the correct status code is being returned, the problem is that an intermediate proxy is timing out. "The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the URI." (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.5) It most likely indicates that the origin server is having some sort of issue (i.e., taking a long time to process your request), so it's not responding quickly.
Perhaps the best solution is to re-craft your server app so that it responds with a "303 See Other" status code; then your client can retrieve the data at a later data point, once the server is done processing and creates the final result.
Edit: Another idea is to re-craft your server app so that it responds with a "413 Request Entity Too Large" status code when the request entity size is too large. This will get rid of the error, though it may make your app less useful if it can only process "small" files."
Other possible solutions:
脚本执行期间浏览器可能会超时。
it is possible that the browser timeouts during the script execution.