In 90e710d7672b928ce6bb3ec05f8f2c05338be6c9 the FeaturePolicy middleware
was renamed to PermissionsPolicy as this will be new name of the header
as used by browsers.
The Permissions-Policy header requires a different implementation and
isn't yet supported by all browsers. To avoid having to rename the
middleware in the future, we keep the new name for the Middleware, but
use the old implementation and header name.
There are several `cookies` methods that appear when searching the API
documentation, but none of them are the method commonly used in
controllers.
This makes Action Controller's `cookies` method appear in the search
results, and makes the accompanying `ActionDispatch::Cookies`
documentation more discoverable.
In the same way that requests may need to be excluded from forced SSL,
requests may also need to be excluded from the Host Authorization
checks. By providing this additional flexibility more applications
will be able to enable Host Authorization while excluding requests
that may not conform. For example, AWS Classic Load Balancers don't
provide a Host header and cannot be configured to send one. This means
that Host Authorization must be disabled to use the health check
provided by the load balancer. This change will allow an application
to exclude the health check requests from the Host Authorization
requirements.
I've modified the `ActionDispatch::HostAuthorization` middleware to
accept arguments in a similar way to `ActionDispatch::SSL`. The hosts
configuration setting still exists separately as does the
hosts_response_app but I've tried to group the Host Authorization
settings like the ssl_options. It may make sense to deprecate the
global hosts_response_app if it's only used as part of the Host
Authorization failure response. I've also updated the existing tests
as the method signature changed and added new tests to verify the
exclusion functionality.
When wrapping parameters, `_extract_parameters` is called twice for
every request. In most cases, both the `include` and `exclude` options
will be empty. In that case, we can use a logical check to save
allocation of an empty array and another allocation of a new array
concatenating the empty array with the hard-coded `EXCLUDE_PARAMETERS`.
The result is 4 array allocations less per request when wrapping is
enabled and `exclude` is not set.
This commit allows Action Text to be used without having an
ApplicationController defined. In doing so, it also fixes Action Text
attachments to render the correct URL host in mailers.
It also avoids allocating an ActionController::Renderer per request.
Fixes#37183.
Fixes#35578.
Fixes#36963.
Closes#38714.
Co-authored-by: Jeremy Daer <jeremydaer@gmail.com>
by setting `config.action_dispatch.request_id_header` to the desired value
* Ensure HTTP_X_REQUEST_ID presence to maintain compatiblility
* Use req.headers[] to fetch header rather than ENV methods
* Update configuration doc to match existing descriptions
* Add changelog entry for action_dispatch.request_id_header
if the action does not use a custom encoding, then we can skip checking if we need to fix the encoding on any of the parameters.
Instead of asking the controller about each of the parameters, we can ask the controller to tell us what params to convert once. If the controller returns nothing, we have no work to do.
previously you could skip encoding which would encode all parameters on an action as ASCII_8BIT
After this change you can specify the `param_encoding` for any one parameter on an action
Co-authored-by: John Hawthorn <jhawthorn@github.com>
Devs may be running tests on a machine which provides $MEMCACHE_SERVERS
without a trailing port. We should allow for this when checking if
Memcache is working.
In https://github.com/rails/rails/pull/37919, support
for rendering objects that respond_to render_in in
controllers was added. However, the implementation
did not support layouts.
This change updates the implementation from #37919
to more closely match the rest of the
ActionView::Template classes, enabling the use of layouts.
Co-authored-by: Felipe Sateler <fsateler@gmail.com>
To be able to distinguish from other kinds of `Mime::Type::InvalidMimeType` that may be raised by user or third-party code. It's only failure in parsing client-supplied content-types in ActionDispatch::Http::MimeNegotiation that should result in special handling.
This also allows third-party error handling/tracking code to specifically target the new `ActionDispatch::Http::MimeNegotiation::InvalidType` for ignoring or other special handling, separate from `Mime::Type::InvalidMimeType`
This is a revision of #35753 in response to #37620 and discussion with @eugeneius