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.
We added a deprecation warning for these cases in aa1fadd, so these are now
causing deprecation warnings in the test output. AFAICT, in these two cases, the
option is not integral to the purpose of the test, so they can be safely removed
Follow up to 212057b9. Since that commit, we need to pass the `route_name`
explicitly. This is one of the left-over cases that was not handled in that
commit, which was causing `use_route` to be ignored in functional tests.
In cases where this option is set to `true`, the option is redundant and can
be safely removed; otherwise, the corresponding `*_url` helper should be
used instead.
Fixes#17294.
See also #17363.
[Dan Olson, Godfrey Chan]
The scanner in Journey fails to recognize routes that use literals
from the sub-delims section of RFC 3986.
This commit enhance the compatibility of Journey with the RFC by
adding support of authorized delimiters to the scanner.
Fix#17212
Request#check_method would use to_sentence(locale: :en), which breaks when
I18n.available_locales does not include :en and
I18n.enforce_available_locales is true (default).
Inlined to_sentence functionality to solve this.
Hash#keys.each allocates an array of keys; Hash#each_key iterates through the
keys without allocating a new array. This is the reason why Hash#each_key
exists.
This reverts commit 9d05d6de52871e57bfbf54a60de005e8a5f5b0e4, reversing
changes made to 0863c9248fd47a15e88e05ce4fcd80966684c0e3.
The change in the behaviour reported at #16958 doesn't exist since 4.0
and 4.1 works in the same way
As of rack/rack@167b648023, Rack raises
Rack::Utils::ParameterTypeError which inherits TypeError.
In terms of the behavior, Rescuing TypeError still works but this
method shouldn't rescue if TypeError is raised for other reasons.
Goals:
1. Default to :random for newly generated applications
2. Default to :sorted for existing applications with a warning
3. Only show the warning once
4. Only show the warning if the app actually uses AS::TestCase
Fixes#16769
We're seeing too many failures to believe otherwise.
This reverts commits bc116a55ca3dd9f63a1f1ca7ade3623885adcc57,
cbde413df3839e06dd14e3c220e9800af91e83ab,
bf0a67931dd8e58f6f878b9510ae818ae1f29a3a, and
2440933fe2c27b27bcafcd9019717800db2641aa.
Dir.glob can be a security concern. The original use was to provide logic of fallback files. Example a request to `/` should render the file from `/public/index.html`. We can replace the dir glob with the specific logic it represents. The glob {,index,index.html} will look for the current path, then in the directory of the path with index file and then in the directory of the path with index.html. This PR replaces the glob logic by manually checking each potential match. Best case scenario this results in one less file API request, worst case, this has one more file API request.
Related to #16464
Update: added a test for when a file of a given name (`public/bar.html` and a directory `public/bar` both exist in the same root directory. Changed logic to accommodate this scenario.
- don't mutate PATH_INFO in env, test
- test fallback content type matches Rack::File
- change assertion style
- make HTTP_ACCEPT_ENCODING comparison case insensitive
- return gzip path from method instead of true/false so we don't have to assume later
- don't allocate un-needed hash.
Original comments:
https://github.com/rails/rails/commit/
cfaaacd9763642e91761de54c90669a88d772e5a#commitcomment-7468728
cc @jeremy
c64bff2c87
added support and enabled parallel execution of the actionpack tests.
However it introduced c64bff2c87
since one cannot connect to a socket file that's inside a Vagrant synced folder
due to security restrictions, and DRb tries to.
Also rename the temporary files to make it obvious that they're rails-related,
since now they're placed outside the project's directory.
Fixes c64bff2c87
Follow up to rails#15321
Instead of duplicating the routes, we will first match the HEAD request to
HEAD routes. If no match is found, we will then map the HEAD request to
GET routes.
If someone is using ActionDispatch::Static to serve assets and makes it past the `match?` then the file exists on disk and it will be served. This PR adds in logic that checks to see if the file being served is already compressed (via gzip) and on disk, if it is it will be served as long as the client can handle gzip encoding. If not, then a non gzip file will be served.
This additional logic slows down an individual asset request but should speed up the consumer experience as compressed files are served and production applications should be delivered with a CDN. This PR allows a CDN to cache a gzip file by setting the `Vary` header appropriately. In net this should speed up a production application that are using Rails as an origin for a CDN. Non-asset request speed is not affected in this PR.
This merges in the code from the breach-mitigation-rails gem that masks
authenticity tokens on each request by XORing them with a random set of
bytes. The masking is used to make it impossible for an attacker to
steal a CSRF token from an SSL session by using techniques like the
BREACH attack.
The patch is pretty simple - I've copied over the [relevant
code](https://github.com/meldium/breach-mitigation-rails/blob/master/lib/breach_mitigation/masking_secrets.rb)
and updated the tests to pass, mostly by adjusting stubs and mocks.
