aboutsummaryrefslogtreecommitdiffstats
path: root/railties/test/application/middleware_test.rb
Commit message (Collapse)AuthorAgeFilesLines
* Multipart file uploads are very rare in API only apps so don't include ↵Guillermo Iguaran2018-02-171-2/+1
| | | | Rack::TemfileReaper in default middleware stack for API only apps
* Add Rack::TempfileReaper to tests and docsGeorge Claghorn2018-01-301-2/+4
|
* Handle `FrozenError` if it is availableYasuo Honda2017-12-201-1/+1
| | | | | | | | | | | | | | | This pull request handles `FrozenError` introduced by Ruby 2.5. Refer https://bugs.ruby-lang.org/projects/ruby-trunk/repository/revisions/61131 Since `FrozenError` is a subclass of `RuntimeError` minitest used by master branch can handle it, though it would be better to handle `FrozenError` explicitly if possible. `FrozenError` does not exist in Ruby 2.4 or lower, `frozen_error_class` handles which exception is expected to be raised. This pull request is intended to be merged to master, then backported to `5-1-stable` to address #31508
* Add DSL for configuring Content-Security-Policy headerAndrew White2017-11-271-0/+1
| | | | https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy
* Fix RuboCop offensesKoichi ITO2017-08-161-1/+1
| | | | And enable `context_dependent` of Style/BracesAroundHashParameters cop.
* Adding frozen_string_literal pragma to Railties.Pat Allan2017-08-141-0/+2
|
* Revert "Merge pull request #29540 from kirs/rubocop-frozen-string"Matthew Draper2017-07-021-1/+0
| | | | | This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
* Enforce frozen string in RubocopKir Shatrov2017-07-011-0/+1
|
* Enforce middleware ordering with a test, instead of commentsMatthew Draper2016-12-311-3/+34
| | | | | | | | | We want the actual order to be very predictable, so it's rightly defined in code -- not with an on-the-fly tsort. But we can do the tsort here, and then verify that it matches the implemented ordering. This way we don't leave future readers guessing which parts of the ordering are deliberate and which are arbitrary.
* Merge pull request #27515 from ↵Matthew Draper2016-12-311-2/+2
|\ | | | | | | | | | | kbrock/fix_log_remote_ip_before_dispatcher_ips_settings Allow log remote ip addres when config.action_dispatch.trusted_proxie…
| * Allow log remote ip addres when config.action_dispatch.trusted_proxies passedLeonid Batizhevsky2016-12-301-1/+1
|/
* "Use assert_nil if expecting nil. This will fail in minitest 6."Akira Matsuda2016-12-251-2/+2
|
* Remove deprecated code in ssl middlewareRafael Mendonça França2016-10-101-2/+2
|
* Remove deprecated support to :text in renderRafael Mendonça França2016-10-101-4/+4
|
* improve error message when include assertions failMichael Grosser2016-09-161-12/+12
| | | | | | assert [1, 3].includes?(2) fails with unhelpful "Asserting failed" message assert_includes [1, 3], 2 fails with "Expected [1, 3] to include 2" which makes it easier to debug and more obvious what went wrong
* Add three new rubocop rulesRafael Mendonça França2016-08-161-1/+1
| | | | | | | | Style/SpaceBeforeBlockBraces Style/SpaceInsideBlockBraces Style/SpaceInsideHashLiteralBraces Fix all violations in the repository.
* applies new string literal convention in railties/testXavier Noria2016-08-061-5/+5
| | | | | The current code base is not uniform. After some discussion, we have chosen to go with double quotes by default.
* Remove unused boot_rails method and it's usagePrathamesh Sonpatki2016-07-041-1/+0
| | | | | - The `boot_rails` method from abstract_unit.rb is empty after 2abcdfd978fdcd491576a237e8c6b. - So let's remove it and its usage.
* Fix etag expectation to work with the SHA256Rafael Mendonça França2016-05-061-1/+1
| | | | It is related with https://github.com/rack/rack/commit/7b66d2cdb80a4d6b44fa8c61d92e25fbbda1f152
* Publish AS::Executor and AS::Reloader APIsMatthew Draper2016-03-021-22/+4
| | | | | | 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.
* Replace `serve_static_files` in tests with `public_file_server.enabled`.Kasper Timm Hansen2015-11-041-2/+2
| | | | Forgot to do it in 748b2f9, when deprecating `serve_static_files`.
* Revert "removing Rack::Runtime from the default stack."Aaron Patterson2015-10-031-9/+11
| | | | | | | | | | | | | | | | | | 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-11/+9
| | | | | | | | | | | | 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-2/+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-7/+7
|
* Soften the lock requirements when eager_load is disabledMatthew Draper2015-07-091-4/+21
| | | | | 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-0/+27
| | | | when true
* Allow Rack::Runtime to be deleted from middleware stack.Guo Xiang Tan2015-02-191-0/+16
| | | | Fixes: https://github.com/rails/rails/issues/16433.
* Merge pull request #18100 from chancancode/serve_static_filesGodfrey Chan2014-12-191-2/+2
| | | | | | Allow static asset serving from env variable (enhanced!) Conflicts: railties/CHANGELOG.md
* inject Rack::Lock if config.eager_load is falseXavier Noria2014-09-181-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Expectations firstAkira Matsuda2014-08-281-1/+1
|
* We don't need parenthesis for thisGuillermo Iguaran2014-08-051-1/+1
|
* Fix digest ETAG test.Arthur Neves2014-08-051-1/+1
| | | | | | After https://github.com/rack/rack/commit/12528d4567d8e6c1c7e9422fee6cd8b43c4389bf ETag will include a `W/` before the digest.
* Merge pull request #12365 from jbaudanza/reorderGuillermo Iguaran2013-12-011-1/+1
|\ | | | | Move Rack::Cache after ActionDispatch::Static in the middleware stack
| * Move Rack::Cache after AD::Static in the stackJonathan Baudanza2013-09-251-1/+1
| |
* | Expose MiddlewareStack#unshift to environment configuration.Ben Pickles2013-10-091-0/+6
|/
* Added CheckPending middleware in defaultArun Agrawal2013-07-151-0/+4
| | | | | | | | | As this middleware comes by default in a new rails app Added test to check omit for CheckPending when Active Record is not included.
* No need to add config for x_sendfile_headerArun Agrawal2013-07-151-2/+0
| | | | Rack::Sendfile is loaded by default now
* Rack::Sendfile is now included in middleware by default, change tests to ↵Guillermo Iguaran2013-07-151-10/+4
| | | | reflect that
* Calls to the application constant have been refactored to usewangjohn2013-06-101-2/+2
| | | | | Rails.application when drawing routes and creating other configurations on the application.
* Testing CheckPending middlewareArun Agrawal2013-06-081-0/+8
|
* Bring config.allow_concurrency backJosé Valim2013-03-031-0/+6
| | | | | Since the Rack::Lock still exists in development, let's provide a way to disable it explicitly.
* Remove BestStandardsSupport middlewareGuillermo Iguaran2013-01-291-2/+1
|
* Don't use action_controller.perform_caching to enable rack-rack.Rafael Mendonça França2012-10-181-4/+1
| | | | | Setting the action_dispatch.rack_cache options to true or a hash should be the way to enable it.
* Use Ruby 1.9 Hash syntax in railtiesRobin Dupret2012-10-141-4/+4
|
* config.action_dispatch.rack_cache should set explicitly to enable Rack::CacheGuillermo Iguaran2012-10-041-1/+10
|
* Remove unused require.kennyj2012-08-291-2/+0
|
* Remove allow_concurrency as a flagJosé Valim2012-08-211-2/+2
| | | | | | | | | | | | | | | | The flag was mainly used to add a Rack::Lock middleware to the stack, but the only scenario the lock is desired is in development. If you are deploying on a not-threaded server, the Rack::Lock does not provide any benefit since you don't have concurrent accesses. On the other hand, if you are on a threaded server, you don't want the lock, since it defeats the purpose of using a threaded server. If there is someone out there, running on a thread server and does want a lock, it can be added to your environment as easy as: `use Rack::Lock`
* Remove ActionDispatch::Head middleware in favor of Rack::HeadSantiago Pastorino2012-07-231-1/+1
| | | | Closes #7110 there's more work to do on rack-cache issue 69
* Freeze the middleware stack after it's builtJeremy Kemper2012-04-201-0/+7
| | | | | | So apps that accidentally add middlewares later aren't unwittingly dumping them in a black hole. Closes #5911
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-02 16:21:58 +0000