We've started on discouraging the usage of `render :text` in #12374.
This is a follow-up commit to make sure that we print out the
deprecation warning.
This is another take at #14384 as we decided to wait until `master` is
targeting Rails 5.0. This commit is implementation-complete, as it
guarantees that all the public methods on the hash-inherited Parameters
are still working (based on test case). We can decide to follow-up later
if we want to remove some methods out from Parameters.
We shouldn't depend on specific methods imlemented in the TestResponse
subclass because the response could actually be a real response object.
In the future, we should either push the aliased predicate methods in
TestResponse up to the real response object, or remove them
The concurrent-ruby gem is a toolset containing many concurrency
utilities. Many of these utilities include runtime-specific
optimizations when possible. Rather than clutter the Rails codebase with
concurrency utilities separate from the core task, such tools can be
superseded by similar tools in the more specialized gem. This commit
replaces `ActiveSupport::Concurrency::Latch` with
`Concurrent::CountDownLatch`, which is functionally equivalent.
We should convert request parameters to a query string, then let the
request object parse that query string. This should give us results
that are more similar to the real-world
Instead of trying to manually clear out a request object, lets just
allocate a new one. The rack ENV is reused and cleaned (still), but the
request object is not.
Variants are typically set in the controller based on some attribute of
the request that the browser sent. We should make our tests more in
line with reality by doing the same and not mutating the request object.
Using `assert_predicate` and `assert_match` instead of just `assert` is
preferrable because better error messages are output.
In the case of `assert response.cookies.empty?` the error message was
`Failed assertion, no message given.` but now with `assert_predicate` it
will be `Expected {"user_name"=>"david"} to be empty?.`
For `assert_match(/user_name=david/,
response.headers["Set-Cookie"])` as well, the message returned was
unhelpful - `Failed assertion, no message given.` but now will tell what
was expected and what was returned with `Expected /user_name=david/ to
match "user_name=nope; path=/".`
Add the possibility to only filter parameters based on
their full path instead of relying on the immediate key.
config.filter_parameters += ['credit_card.code']
{ 'credit_card' => { 'code' => '[FILTERED]' },
'source' => { 'code' => '<%= puts 5 %>' } }
In 0de4a23 the behavior when there is a missing template was changed to
not raise an error, but instead head :no_content. This is a breaking
change and some gems rely on this happening.
To allow gems and other code to work around this, allow
`default_render` to take a block which, if provided, will
execute the contents of that block instead of doing the `head :no_content`.
This reverts commit 0b3397872582f2cf1bc6960960a6393f477c55e6, reversing
changes made to 56d52e3749180e6c1dcf7166adbad967470aa78b.
As pointed out on the PR, this will hide development mistakes too, which
is not ideal.
People should be free to mutate the header object, but not to set a new
header object. That header object may be specific to the webserver, and
we need to hide it's internals.
`ActionDispatch::SSL` changes headers to `Hash`.
So some headers will be broken if there are some middlewares
on ActionDispatch::SSL and if it uses `Rack::Utils::HeaderHash`.
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`.
ParamsWrapper was initially removed from API controllers according to
the following discusision:
https://github.com/rails-api/rails-api/issues/33
However, we're including it again so Rails API devs can decide
whether to enable or disable it.
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"`.
When 7e504927 was merged setting `Encoding.default_internal` and
`Encoding.default_external` would throw a warning when the ActionPack
tests were run.
Example warning: `actionpack/test/dispatch/static_test.rb:12: warning:
setting Encoding.default_external`
This patch silences the warnings as other similar tests do for setting
default_internal and default_external.
After merging #19377 ActionPack tests were missing a require for
`ActiveSupport::LogSubscriber::TestHelper` and change didn't take
into account that logger could be nil. Added the require and only log to
info if logger exists.
This wasn't caught earlier because these tests only run after a merge.
The initial attempt was to remove the method at all in
4926aa68c9.
The method overrides Rack's `#form_data?`
6f8808d420/lib/rack/request.rb (L172-L184).
Which may have some incorrect implementation actually. `type.nil?` isn't possible I suppose. I'll check.
The current implementation of ActionController::Parameters.const_missing
returns `ActionController::Parameters.always_permitted_parameters` even
if its `super` returns a constant without raising error. This prevents its
subclass in a autoloading module/class from taking advantage of
autoloading constants.
class SomeParameters < ActionController::Parameters
def do_something
DefinedSomewhere.do_something
end
end
In the code above, `DefinedSomewhere` is to be autoloaded with
`Module.const_missing` but `ActionController::Parameters.const_missing`
returns `always_permitted_parameters` instead of the autoloaded
constant.
This pull request fixes the issue respecting `const_missing`'s `super`.
Previously, an empty X_FORWARDED_HOST header would cause
Actiondispatch::Http:URL.raw_host_with_port to return nil, causing
Actiondispatch::Http:URL.host to raise a NoMethodError.
Fixes the issue described in #18764 - prevents Rack middleware from
swallowing up HEAD requests that should have been matched by a
higher-precedence `get` route, but still allows Rack middleware to
respond to HEAD requests.
Preserving RACK_ENV behavior.
This reverts commit 7bdc7635b885e473f6a577264fd8efad1c02174f, reversing
changes made to 45786be516e13d55a1fca9a4abaddd5781209103.
ActionDispatch::IntegrationTest HTTP request methods will accept only
certain kwargs in the future. This test caused a deprecation warning
when running ActionPack tests. Added `params` and `headers` to fix.
As of the upgrade to Rack 1.5, request.session_options[:id] is no
longer populated. Reflect this change in the tests by using
request.session.id instead.
Related change in Rack:
https://github.com/rack/rack/commit/83a270d6
This fixes the reasons 4cf3b8a, 303567e, and fa63448 needed to be
reverted in 7142059. The revert has been reverted and this fixes
the issues caused previously.
If we call `super` first we will end up nuking the session settings in the
application tests that do `setup do` - so any session login or cookie
settings will not be persisted thoughout the test sessions.
Calling `super` last prevents `@integration_session` from getting nuked
and set to nil if it's already set.
Test added to prevent regression of this behavior in the future.
Since the `ForkingExecutor` class seems to be pretty slow on Rubinius
due to DRb (c.f. http://git.io/xIVg), let's avoid running tests with
it on this platform.
Also, the `parallelize_me!` call make the suite to output a bunch of
errors due to rubinius/rubinius#2934 since there are thread-safety
problems with autoloading.
In f6e293ec54f02f83cdb37502bea117f66f87bcae we avoided a segfault in the
tests, however I think we should try to avoid the crash, as it may
happen in user code as well.
Here is what I distiled the bug down to:
```ruby
# Rails case - works on 2.0, 2.1; crashes on 2.2
require 'action_dispatch'
ActionDispatch::Response.new(200, "Content-Type" => "text/xml")
# General case - works on 2.0, 2.1; crashes on 2.2
def foo(optional = {}, default_argument: nil)
end
foo('quux' => 'bar')
```
Introduced in f6e293e ActionPack tests began sefaulting. I found that it
was the kwargs and the test causing the seg fault was missing the new
default_headers argument.
Haven't diagnosed yet. No similarly failing tests in Rails to work from.
cc @tenderlove, @eileencodes
Revert "there is always an integration session, so remove the check"
Revert "lazily create the integration session"
Revert "use before_setup to set up test instance variables"
This reverts commits 4cf3b8ac47f109fa83a6f66eb97d6cb0eace0d05, 303567e554de26822f3107be55c471d6477a745f, and fa63448420d3385dbd043aca22dba973b45b8bb2.
Partitioning of all the routes is currently being done during the
first request. Since there is no need to clear the cache for
`partitioned_routes` when adding a new route. We can move the
partitioning of the routes during setup time.
Fixes regression in #18423. Merge default headers for new responses,
but don't merge when creating a response from the last session request.
hat tip @senny ❤️
Fixed an issue where the `RAILS_RELATIVE_URL_ROOT` environment
variable is not prepended to the path when `url_for` is called.
If `SCRIPT_NAME` (used by Rack) is set, it takes precedence.
As part of #19029, in future `skip_before_action`, `skip_after_action` and
`skip_around_action` will raise an ArgumentError if the specified
callback does not exist. `skip_action_callback` calls all three of these
methods and will almost certainly result in an ArgumentError. If anyone
wants to remove all three callbacks then they can still call the three
individual methods. Therefore let's deprecate `skip_action_callback` now
and remove it when #19029 is merged.
Change filter on /rails/info/routes to use an actual path regexp from rails
and not approximate javascript version. Oniguruma supports much more
extensive list of features than javascript regexp engine.
Fixes#18402.
Collections can take advantage of `multi_read` if they render one template
and their partials begin with a cache call.
The cache call must correspond to either what the collections elements are
rendered as, or match the inferred name of the partial.
So with a notifications/_notification.html.erb template like:
```ruby
<% cache notification %>
<%# ... %>
<% end %>
```
A collection would be able to use `multi_read` if rendered like:
```ruby
<%= render @notifications %>
<%= render partial: 'notifications/notification', collection: @notifications, as: :notification %>
```
Add http_cache_forever to ActionController, so we can cache results
forever.
Things like static pages are a good candidate for this type of caching.
This cache only controls caching headers, so it is up to the browser to
cache those requests.
The methods `fresh_when` and `stale?` from ActionController::ConditionalGet
accept a single record as a short form for a hash. For instance
```ruby
def show
@article = Article.find(params[:id])
fresh_when(@article)
end
```
is just a short form for:
```ruby
def show
@article = Article.find(params[:id])
fresh_when(etag: @article, last_modified: @article.created_at)
end
```
This commit extends `fresh_when` and `stale?` to also accept a collection
of records, so that a short form similar to the one above can be used in
an `index` action. After this commit, the following code:
```ruby
def index
@article = Article.all
fresh_when(etag: @articles, last_modified: @articles.maximum(:created_at))
end
```
can be simply written as:
```ruby
def index
@article = Article.all
fresh_when(@articles)
end
```
PR #18772 changed the parameters of `stale?` to use `kwargs`.
[As for this comment](https://github.com/rails/rails/pull/18872/files#r24456288)
the default value for the `etag` parameter should be `record`, not `nil`.
This commit fixes the code and introduces a test that:
- passed before #18872
- fails on the current master (after #18772)
- passes again after setting the default value of `etag` to `record`.
In match_head_routes, deleted the routes in which request.request_method was empty (matches all HTTP verbs) when responding to a HEAD request. This prevents catch-all routes (such as Racks) from intercepting the HEAD request.
Fixes#18698
This is an issue brought up by @daniel-rikowski in rails/web-console#91.
Citing his PR proposal here:
> Prior to this, backtrace lines were simply split by a single colon.
>
> Unfortunately that is also the drive letter delimiter in Windows paths
> which resulted in a lot of empty source fragments of "C:0". ("C" from
> the drive letter and 0 from "/path/to/rails/file.rb:16".to_i)
>
> Now the trace line is split by the first colon followed by some digits,
> which works for both Windows and Unix path styles.
Now, the PR was sent against web-console, because of the templates copy
issue we used to had. Instead of bothering the contributor to reopen the
issue against upstream Rails itself, I will make sure he gets the credit
by putting his name in [rails-contributors/hard_coded_authors.rb][].
[rails-contributors/hard_coded_authors.rb]: (https://github.com/fxn/rails-contributors/blob/master/app/models/names_manager/hard_coded_authors.rb).
Non-kwargs requests are deprecated now.
Guides are updated as well.
`post url, nil, nil, { a: 'b' }` doesn't make sense.
`post url, params: { y: x }, session: { a: 'b' }` would be an explicit way to do the same
Inside a controller functional test after the last flash is deleted it
still persists the flash because to_session_value is nil. We should
delete it from the session when the serialized version is nil, same as
the flash middleware.
Fixes an issue that would cause default_url_options to be lost when generating
URLs with fewer positional arguments than parameters in the route definition.
Shorthand route match is when controller and action are taken literally from path.
E.g.
get '/foo/bar' # => will use 'foo#bar' as endpoint
get '/foo/bar/baz' # => will use 'foo/bar#baz' as endpoint
Not any path with level two or more of nesting can be used as shortcut.
If path contains any characters outside of /[\w-]/ then it can't be
used as such.
This commit ensures that invalid shortcuts aren't used.
':controller/:action/postfix' - is an example of invalid shortcut
that was previosly matched and led to exception:
"ArgumentError - ':controller/:action' is not a supported controller name"
This allows the test to mirror the production code, since `via: :all` is
a valid option. The behavior in 4.1 did not actually test that it
matched all verbs, but instead defaulted to testing for "GET". This
implementation aims to better handle the intention of passing "all".
What will actually be asserted doesn't quite match up with the generated
route, since it appears to just not create a constraint on the method.
However, I don't think that we can easily test the lack of that
constraint. Testing each of the main 4 HTTP verbs seems to be a
reasonably close approximation, which should be sufficient for our
needs.
Fixes#18511.
When `render` was moved from ActionPack to ActionView in acc8e259,
some fixtures required by the tests were duplicated, but they are
actually only required by ActionView tests.
To give one example, `double_render` is already defined [in the AV tests](72139d8d31/actionview/test/actionpack/controller/render_test.rb (L407))
and is never used in the ActionPack tests.
The new test/docs further explain the conflicts that can happen when
mixing `:if`/`:unless` options with `:only`/`:except` options in
`skip_before_action`.
The gist is that "positive" filters always have priority over negative
ones.
The previous commit already showed that `:only` has priority over `:if`.
This commit shows that `:if` has priority over `:except`.
For instance, the following snippets are equivalent:
```ruby
skip_before_action :some_callback, if: -> { condition }, except: action
```
```ruby
skip_before_action :some_callback, if: -> { condition }
```
Test case for using skip_before_filter with the options :only and :if
both present. In this case, the :if option will be ignored and :only
will be executed.
Closes#14549 (the commit was cherry-picked from there).
Commit 20fece1 introduced the `_status_code` method to fix calls to
`head :ok`. This method has been added on both ActionController::Metal
and ActionDispatch::Response.
As for the latter, this method is just equivalent to the `response_code`
one so commit aefec3c removed it from the `Reponse` object so call to
the `_status_code` method on an ActionController::Base instance would be
handled by the `Metal` class (which `Base` inherits from) but the status
code is not updated according to the response at this level.
The fix is to actually rely on `response_code` for ActionController::Base
instances but this method doesn't exist for bare Metal controllers so we
need to define it.
The current implementation of `variants=` don't allow a resetting to nil, wich is the default value.
This results in the following code smell:
```ruby
case request.user_agent
when /iPhone/
request.variants = :phone
when /iPad/
request.variants = :ipad
end
```
With the ability to reset variants to nil, it could be:
```ruby
request.variants = case request.user_agent
when /iPhone/
:phone
when /iPad/
:ipad
end
```
When an `around_action` does not `yield`, then the corresponding action is
*never* executed and the `after_` actions are *never* invoked.
The value returned by the `around_action` does not have any impact on this:
an `around_action` can "return" `true`, `false`, or `"pizza"`, but as long
as `yield` is not invoked, the corresponding action and after callbacks are
not executed.
The test suite for `ActionController::Callbacks` currently includes separate
tests to distinguish the cases in which a non-yielding `around_actions` returns
`true` or `false`.
In my opinion, having such tests is misleading, giving the impression that the
returned value might have some sort of impact, while it does not. At least
that's the impression I got when I read those tests.
For completeness, the tests were introduced 7 years ago by @NZKoz in e80fabb.
There is no need to subtract one from the path_params size when there is
no format parameter because it is not present in the path_params array.
Fixes#17819.
As suggested in #16299([1]), this method should be a new public API for
retrieving unfiltered parameters from `ActionController::Parameters`
object, given that `Parameters#to_hash` will no longer work in Rails
5.0+ as we stop inheriting `Parameters` from `Hash`.
[1]: https://github.com/rails/rails/pull/16299#issuecomment-50220919
This fixes a regression in 4.2.0 from 4.1.8.
https://github.com/rails/rails/pull/17823 fixed a similar regression regarding _explicitly_ named routes for a mounted Rack app, but there was another regression for the default value.
With a route like:
Rails.application.routes.draw do
mount Mountable::Web, at: 'some_route'
end
The "Prefix" column of rake routes gives the following:
- 4.1.8: mountable_web
- 4.2.0.beta1-4: [nothing]
- 4.2.0.rc1: [nothing]
- 4.2.0.rc2: some_route <- regression
This fixes the default to go back to being based off the name of the class like the docs specify: 785d04e310/actionpack/lib/action_dispatch/routing/mapper.rb (L558-L560)
Explicitly named routes still work correctly per https://github.com/rails/rails/pull/17823:
Rails.application.routes.draw do
mount Mountable::Web, at: 'some_route', as: 'named'
end
- 4.1.8: named
- 4.2.0.beta1-4: [nothing]
- 4.2.0.rc1: [nothing]
- 4.2.0.rc2: named
Some `require 'openssl'` statements were surrounded by `rescue` blocks to deal with Ruby versions that did not support `OpenSSL::Digest::SHA1` or `OpenSSL::PKCS5`.
[As @jeremy explains](a6a0904fcb (commitcomment-8826666)) in the original commit:
> If jruby didn't have jruby-openssl gem, the require wouldn't work. Not sure whether either of these are still relevant today.
According to the [release notes for JRuby 1.7.13](http://www.jruby.org/2014/06/24/jruby-1-7-13.html):
> jruby-openssl 0.9.5 bundled
which means the above `rescue` block is not needed anymore.
All the Ruby versions supported by the current version of Rails provide those OpenSSL libraries, so Travis CI should also be happy by removing the `rescue` blocks.
---
Just to confirm, with JRuby:
$ ruby --version #=> jruby 1.7.16.1 (1.9.3p392) 2014-10-28 4e93f31 on Java HotSpot(TM) 64-Bit Server VM 1.8.0_20-b26 +jit [darwin-x86_64]
$ irb
irb(main):001:0> require 'openssl' #=> true
irb(main):002:0> OpenSSL::Digest::SHA1 #=> OpenSSL::Digest::SHA1
irb(main):003:0> OpenSSL::PKCS5 # => OpenSSL::PKCS5
And with Ruby 2.1:
$ ruby --version #=> ruby 2.1.2p95 (2014-05-08 revision 45877) [x86_64-darwin13.0]
$ irb
irb(main):001:0> require 'openssl' #=> true
irb(main):002:0> OpenSSL::Digest::SHA1 #=> OpenSSL::Digest::SHA1
irb(main):003:0> OpenSSL::PKCS5 #=> OpenSSL::PKCS5
This will help you debug missing template errors, especially if they
come from a programmatic template selection. Thanks to @dhh for
suggesting that.
As a bonus, also show request and response info on the routing error
page for consistency.
This reverts commit f93df52845766216f0fe36a4586f8abad505cac4, reversing
changes made to a455e3f4e9dbfb9630d47878e1239bc424fb7d13.
Conflicts:
actionpack/lib/action_controller/test_case.rb
actionview/lib/action_view/test_case.rb
Those three can be nil when exception backtrace is nil. This happens and
that forced a couple of nil guards in the code. I'm proposing to make
those always return an array, even on nil backtrace.
