我有一个在Ruby 2.1.1上运行Rails 4.1.5的heroku应用程序。
该应用程序涉及一些媒体处理，并涉及使用dropzone JS的javascript上传功能，以在稍后的后台作业中处理之前将照片保存在Amazon S3上。
我遇到了一个非常令人沮丧的问题。根据互联网连接的速度，Heroku路由器会间歇性地以H15（空闲连接）状态终止上传操作。我不相信连接真的闲置了，因为使用相同的互联网连接，我可以将类似的文件上传到其他网站。
这与网络dyno的超时无关，因为在路由器首先关闭的情况下，请求永远不会到达dyno。
这里会发生什么？
注意：我已经实现了这种CORS处理技术：http://www.tsheffler.com/blog/?p=428
日志：
[时间戳]heroku[路由器]：at=错误代码=H15 desc="空闲连接"方法=POST路径="/console/breads/57-YAMTALE/photos"主机=[主机]请求id=634d7680-8b66-4123-a4bc-fe78dc4e7b90 fwd="[IP]"dyno=web.1连接=0ms服务=90232ms状态=503字节=0
Procfile:
web:bundle exec rails server thin-p\$PORT-e\$RACK_ENV
可能相关的宝石：
宝石"薄"
宝石"载波"
gem"carrierwave_backgrounder"
gem'rmagick'，：require=>'rmagick'
gem‘aws-sdk’
gem"rack-cors"，：require=>"rack/cors"
gem"守护进程"
gem"exception_notification"
您需要直接将大文件上传到S3（或等效文件），而不是通过Heroku应用程序。您可以将urn发布到您的应用程序（可能使用javascript），然后在后台处理从/到S3的过程。
不幸的是，这也牵涉其中。
Heroku在这里有（实际上非常好的）关于一种特殊方法的说明：https://devcenter.heroku.com/articles/direct-to-s3-image-uploads-in-rails
详细信息
如果Heroku路由器在30秒内没有接收到第一个字节，它将超时。此后，它将跟踪55秒的滚动窗口，该窗口在字节向上或向下传输时被重置。https://devcenter.heroku.com/articles/request-timeout
在你的情况下，我猜你的上传有时需要超过30秒。尽管您将文件作为后台任务进行处理，但我猜您在上传完成之前不会发回第一个字节。因此出现了间歇性超时。
在上述Heroku文件中：
许多web应用程序允许用户上传文件。当这些文件较大，或者用户的互联网连接速度较慢，上传可能需要30秒以上的时间。对此，我们直接建议上传到S3。
分块上传
我相信有另一种方法可以解决这个问题，使用HTTP分块上传，第一个字节的响应可以在早期发送。（这只适用于支持55秒滚动窗口的Cedar 1.1和更新版本）
事实上，分块方法应该比上面的直接到S3方法更简单。我从来没有跟进过这件事，有几个原因：
1） Heroku没有将其作为一种选择。
2） 这将违背Heroku的一般建议：
最佳做法是将您的web应用程序的响应时间控制在>500ms以下，这将使应用程序能够满足更多请求，并为您的访问者提供高质量的用户体验。
3） 它可能（根据我的理解，它会）对Heroku的负载平衡产生负面影响，而负载平衡是原始的（或者根据你问谁而崩溃）。