Similar to b744372f2dfd3d86f7eb4af99b1f9049e21f3d44, this defers loading
`ActionDispatch::Response` until after initialization, which will allow
applications to boot a bit faster in development but also paves the way
for `return_only_media_type_on_content_type` to work correctly when set
from `new_framework_defaults_6_0.rb`.
Benchmark:
$ cat test.rb
require "bundler/setup"
before = ObjectSpace.each_object(Module).count
start = Process.clock_gettime(Process::CLOCK_MONOTONIC)
require "action_controller"
finish = Process.clock_gettime(Process::CLOCK_MONOTONIC)
after = ObjectSpace.each_object(Module).count
puts "took #{finish - start} and created #{after - before} modules"
Before:
$ ruby test.rb
took 0.35654300000169314 and created 608 modules
After:
$ ruby test.rb
took 0.2770050000108313 and created 466 modules
Co-authored-by: Serena Fritsch <serena@intercom.io>
A HTTP feature policy is Yet Another HTTP header for instructing the
browser about which features the application intends to make use of and
to lock down access to others. This is a new security mechanism that
ensures that should an application become compromised or a third party
attempts an unexpected action, the browser will override it and maintain
the intended UX.
WICG specification: https://wicg.github.io/feature-policy/
The end result is a HTTP header that looks like the following:
```
Feature-Policy: geolocation 'none'; autoplay https://example.com
```
This will prevent the browser from using geolocation and only allow
autoplay on `https://example.com`. Full feature list can be found over
in the WICG repository[1].
As of today Chrome and Safari have public support[2] for this
functionality with Firefox working on support[3] and Edge still pending
acceptance of the suggestion[4].
#### Examples
Using an initializer
```rb
# config/initializers/feature_policy.rb
Rails.application.config.feature_policy do |f|
f.geolocation :none
f.camera :none
f.payment "https://secure.example.com"
f.fullscreen :self
end
```
In a controller
```rb
class SampleController < ApplicationController
def index
feature_policy do |f|
f.geolocation "https://example.com"
end
end
end
```
Some of you might realise that the HTTP feature policy looks pretty
close to that of a Content Security Policy; and you're right. So much so
that I used the Content Security Policy DSL from #31162 as the starting
point for this change.
This change *doesn't* introduce support for defining a feature policy on
an iframe and this has been intentionally done to split the HTTP header
and the HTML element (`iframe`) support. If this is successful, I'll
look to add that on it's own.
Full documentation on HTTP feature policies can be found at
https://wicg.github.io/feature-policy/. Google have also published[5] a
great in-depth write up of this functionality.
[1]: https://github.com/WICG/feature-policy/blob/master/features.md
[2]: https://www.chromestatus.com/feature/5694225681219584
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1390801
[4]: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/33507907-support-feature-policy
[5]: https://developers.google.com/web/updates/2018/06/feature-policy
ActionDispatch's default headers are now moved into their own module that are by default included in both Base and API. This allows API-mode applications to take advantage of the default security headers, as well as providing an easy way to add more.
This basically reverts e9fca7668b9eba82bcc832cb0061459703368397, d08da958b9ae17d4bbe4c9d7db497ece2450db5f,
d1fe1dcf8ab1c0210a37c2a78c1ee52cf199a66d, and 68eaf7b4d5f2bb56d939f71c5ece2d61cf6680a3
Abstract Controller is the common component between Action Mailer and
Action Controller so if we need to share the caching component it need
to be there.
- Fixes bug #23142.
- Bug was occurring only with ActionController::API, because `_process_options` wasn't being run for API requests, even though it was being run for normal app requests.
Since all controller instances are required to have a request and
response object, RackDelegation is no longer needed (we always have to
delegate to the response)
New default: the template digest is automatically included in your ETags.
When you call `fresh_when @post`, the digest for `posts/show.html.erb`
is mixed in so future changes to the HTML will blow HTTP caches for you.
This makes it easy to HTTP-cache many more of your actions.
If you render a different template, you can now pass the `:template`
option to include its digest instead:
fresh_when @post, template: 'widgets/show'
Pass `template: false` to skip the lookup. To turn this off entirely, set:
config.action_controller.etag_with_template_digest = false
Method invalid_asset_host! was delegated to controller but sprockets
compile assets in their own scope without controller. And if we set asset_host
with second parameter it should raise error through invalid_asset_host!.
But since controller is nil it cannot be reached.
ActionDispatch::Routing::UrlFor was always required in UrlHelpers. This
was changed by splitting previous implementation of UrlHelper into 2
modules: ActionView::Helpers::UrlHelper and
ActionView::Routing::UrlHelper. The former one keeps only basic
implementation of url_for. The latter adds features that allow to use
routes and is only required when url_helpers or mounted_helpers are
required.
This is another step in moving Action View's dependencies in Action Pack
to Action View itself. Also, HtmlScanner seems to be better suited for
views rather than controllers.
Since it's more about DOM classes and ids it belongs to Action View
better. What's more, it's more convenient to make it part of Action View
to follow the rule that Action Pack can depend on Action View, but not
the other way round.
Since Action View should not depend on actionpack, it's best to delegate
invalid_asset_host! to controller and just rely on such simple contract
instead of raising ActionController::RoutingError directly.
The new option allows any Ruby namespace to be registered and set
up for eager load. We are effectively exposing the structure existing
in Rails since v3.0 for all developers in order to make their applications
thread-safe and CoW friendly.
This is a private place to put those AS features that are used
by every component. Nowadays we cherry-pick individual files
wherever they are used, but that it is not worth the effort
for stuff that is going to be loaded for sure sooner or later,
like blank?, autoload, concern, etc.
