aboutsummaryrefslogtreecommitdiffstats
path: root/railties/lib/rails/application/default_middleware_stack.rb
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #18100 from chancancode/serve_static_filesGodfrey Chan2014-12-191-1/+1
| | | | | | Allow static asset serving from env variable (enhanced!) Conflicts: railties/CHANGELOG.md
* inject Rack::Lock if config.eager_load is falseXavier Noria2014-09-181-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If code is not eager loaded constants are loaded on demand. Constant autoloading is not thread-safe, so if eager loading is not enabled multi-threading should not be allowed. This showed up in certain Capybara scenarios: Most Capybara drivers other than Rack::Test need a web server. In particular, drivers for JavaScript support. Capybara launches WEBrick in its own thread for those but that per se is fine, because the spec thread and the server thread are coordinated. Problem comes if the page being served in the spec makes Ajax calls. Those may hit WEBrick in parallel, and since WEBrick is multi-threaded and allow_concurrency? returns true in the test environment before this patch, threads are spawned to serve those parallel requests. On the other hand, since eager_load is false by default in the test environment, constants are not preloaded. So the suite is autoloading constants in a multi-threaded set. That's a receipt for paracetamol. The symptom is random obscure errors whose messages point somehow to constant autoloading. As a consequence of this fix for allow_concurrency? WEBrick in Capybara scenarios no longer runs in multi-threaded mode. Fixes #15089.
* Move Rack::Cache after AD::Static in the stackJonathan Baudanza2013-09-251-5/+5
|
* Revert "Don't use Rack::Sendfile middleware if x_sendfile_header is not present"Santiago Pastorino2013-07-151-3/+1
| | | | | | | | | | This reverts commit 19ac034bdc9be175eff7cf54208ba14b43d97681. And allows webservers to configure X-Sendfile-Type. Closes #11440 thanks to [@MSch] Conflicts: railties/lib/rails/application.rb
* Creating a class to build the default middleware stack.wangjohn2013-06-161-0/+101
A lot of logic for building the default middleware stack is currently kept in Application class, but this can be encapsulated and made more modular by being moved to its own class. Also refactored a couple of the helper methods.