aboutsummaryrefslogtreecommitdiffstats
path: root/railties/lib/rails/application/default_middleware_stack.rb
Commit message (Collapse)AuthorAgeFilesLines
* Publish AS::Executor and AS::Reloader APIsMatthew Draper2016-03-021-19/+3
| | | | | | These should allow external code to run blocks of user code to do "work", at a similar unit size to a web request, without needing to get intimate with ActionDipatch.
* Flexible configuration for ActionDispatch::SSLTim Rogers2015-12-291-1/+1
|
* DebugException initialize with a response_format valueJorge Bejar2015-12-091-1/+1
|
* Response when error should be formatted properly in Rails API if local requestJorge Bejar2015-12-091-1/+1
|
* Make the `static_index` config part of the `config.public_server` configYuki Nishijima2015-11-161-1/+1
| | | | Also call it `public_server.index_name` so it'll make more sense.
* Add enabled flag to the public file server.Kasper Timm Hansen2015-11-031-1/+1
| | | | | | | | As discussed in https://github.com/rails/rails/pull/19135#issuecomment-153385986. Replaces `serve_static_files` to unify the static options under the `public_file_server` wing. Deprecates `serve_static_files` accessors, but make them use the newer config internally.
* Merge pull request #19135 from yuki24/access-control-supportJeremy Daer2015-10-131-1/+4
|\ | | | | | | Add basic support for access control headers to ActionDispatch::Static
| * Add the ability of returning arbitrary headers to ActionDispatch::StaticYuki Nishijima2015-06-131-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now ActionDispatch::Static can accept HTTP headers so that developers will have control of returning arbitrary headers like 'Access-Control-Allow-Origin' when a response is delivered. They can be configured through `#config.public_file_server.headers`: config.public_file_server.headers = { "Cache-Control" => "public, max-age=60", "Access-Control-Allow-Origin" => "http://rubyonrails.org" } Also deprecate `config.static_cache_control` in favor of `config.public_file_server.headers`.
* | Revert "removing Rack::Runtime from the default stack."Aaron Patterson2015-10-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 37423e4ff883ad5584bab983aceb4b2b759a1fd8. Jeremy is right that we shouldn't remove this. The fact is that many engines are depending on this middleware to be in the default stack. This ties our hands and forces us to keep the middleware in the stack so that engines will work. To be extremely clear, I think this is another smell of "the rack stack" that we have in place. When manipulating middleware, we should have meaningful names for places in the req / res lifecycle **not** have engines depend on a particular constant be in a particular place in the stack. This is a weakness of the API that we have to figure out a way to address before removing the constant. As far as timing attacks are concerned, we can reduce the granularity such that it isn't useful information for hackers, but is still useful for developers.
* | removing Rack::Runtime from the default stack.Aaron Patterson2015-10-021-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | The runtime header is a potential target for timing attacks since it returns the amount of time spent on the server (eliminating network speed). Total time is also not accurate for streaming responses. The middleware can be added back via: ```ruby config.middleware.ues ::Rack::Runtime ```
* | mostly remove the ParamsParser middlewareAaron Patterson2015-09-181-1/+0
| | | | | | | | | | This can still be added to the middleware stack, but is really not necessary. I'll follow up with a commit that deprecates the constant
* | Rely on the load interlock for non-caching reloads, tooMatthew Draper2015-07-091-15/+7
| |
* | Soften the lock requirements when eager_load is disabledMatthew Draper2015-07-091-9/+29
|/ | | | | We don't need to fully disable concurrent requests: just ensure that loads are performed in isolation.
* Add config.api_only option to application and remove appropriate middleware ↵Santiago Pastorino2015-06-111-3/+3
| | | | when true
* Change the `index` arg of `ActionDispatch::Static#new` to a kwargYuki Nishijima2015-06-111-1/+1
|
* config.static_index configures directory index "index.html" filenameEliot Sykes2015-05-281-1/+1
| | | | | | Set `config.static_index` to serve a static directory index file not named `index`. For example, to serve `main.html` instead of `index.html` for directory requests, set `config.static_index` to `"main"`.
* 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.