| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
Better logging of cached partial renders
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Implement naive partial caching mechanism.
Add test for LogSubscriber
Use ActionView::Base#log_payload to store log_subscriber's payload, so we can pass cache result into it.
Fixed tests
Remove useless settings
Check if #log_payload exists before calling it. Because other classes also includes CacheHelper but don't have is attribute
Use @log_payload_for_partial_reder instead of #log_payload to carry ActionView's payload.
Update test's hash syntax
Add configuration to enable/disable fragment caching logging
Remove unless test and add new test to ensure cache info won't effect next rendering's log
Move :enable_fragment_cache_logging config from ActionView to ActionPack
Apply new config to tests
Update actionview's changelog
Update configuration guide
Improve actionview's changelog
Refactor PartialRenderer#render and log tests
Mute subscriber's log instead of disabling instrumentation.
Fix typo, remove useless comment and use new hash syntax
Improve actionpack's log_subscriber test
Fix rebase mistake
Apply new config to all caching intstrument actions
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In integration test when specify the "Accept" header with "xhr: true"
option, the Accept header is overridden with a default xhr Accept
header. The issue only affects HTTP header "Accept" but not CGI variable
"HTTP_ACCEPT".
For example:
get '/page', headers: { 'Accept' => 'application/json' }, xhr: true
# This is WRONG! And the response.content_type is also affected.
# It should be "application/json"
assert_equal "text/javascript, text/html, ...", request.accept
assert_equal 'text/html', response.content_type
The issue is in `ActionDispatch::Integration::RequestHelpers`. When
setting "xhr: true" the helper sets a default HTTP_ACCEPT if blank.
But the code doesn't consider supporting both HTTP header style and
CGI variable style.
For detail see this GitHub issue:
https://github.com/rails/rails/issues/25859
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a `GET` request is sent `as: :json` in an integration test the test
should use Rack's method override to change to a post request so the
paramters are included in the postdata. Otherwise it will not encode the
parameters correctly for the integration test.
Because integration test sets up it's own middleware,
`Rack::MethodOverride` needs to be included in the integration tests as
well.
`headers ||= {}` was moved so that headers are never nil. They should
default to a hash.
Fixes #26033
[Eileen M. Uchitelle & Aaron Patterson]
|
|
|
|
|
| |
Looked odd, so completely detached from the other necessary part of
the implementation.
|
|
|
|
|
|
| |
The coder that Psych passes in has a `tag` method we can use to detect
which serialization format we're reviving for. Use it and make it clearer
alongside the `load_tags` fiddling.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we were to serialize an `ActionController::Parameters` on Psych 2.0.8, we'd get:
```yaml
--- !ruby/hash:ActionController::Parameters
key: :value
```
Because 2.0.8 didn't store instance variables, while 2.0.9 did:
https://github.com/tenderlove/psych/commit/8f84ad0fc711a82a1040def861cb121e8985fd4c
That, coupled with 2.0.8 calling `new` instead of `allocate` meant parameters was
deserialized just fine:
https://github.com/tenderlove/psych/commit/af308f8307899cb9e1c0fffea4bce3110a1c3926
However, if users have 2.0.8 serialized parameters, then upgrade to Psych 2.0.9+ and
Rails 5, it would start to blow up because `initialize` will never be called, and thus
`@parameters` will never be assigned. Hello, `NoMethodErrors` on `NilClass`! :)
To fix this we register another variant of the previous serialization format and take
it into account in `init_with`.
I've tested this in our app and previously raising code now deserializes like a champ.
I'm unsure how to test this in our suite because we use Psych 2.0.8 and don't know how
to make us use 2.0.9+ for just one test.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By changing ActionController::Parameter's superclass, Rails 5 also changed
the YAML serialization format.
Since YAML doesn't know how to handle parameters it would fallback to its
routine for the superclass, which in Rails 4.2 was Hash while just Object
in Rails 5. As evident in the tags YAML would spit out:
4.2: !ruby/hash-with-ivars:ActionController::Parameters
5.0: !ruby/object:ActionController::Parameters
Thus when loading parameters YAML from 4.2 in Rails 5, it would parse a
hash dump as it would an Object class.
To fix this we have to provide our own `init_with` to be aware of the past
format as well as the new one. Then we add a `load_tags` mapping, such that
when the YAML parser sees `!ruby/hash-with-ivars:ActionController::Parameters`,
it knows to call our `init_with` function and not try to instantiate it as
a normal hash subclass.
|
|\
| |
| | |
Reset rack.input when the environment is scrubbed for the next request
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before this change, posted parameters would leak across requests. The included
test case failed like so:
1) Failure:
TestCaseTest#test_multiple_mixed_method_process_should_scrub_rack_input:
--- expected
+++ actual
@@ -1 +1 @@
-{"bar"=>"an bar", "controller"=>"test_case_test/test", "action"=>"test_params"}
+{"foo"=>"an foo", "bar"=>"an bar", "controller"=>"test_case_test/test", "action"=>"test_params"}
An argument could be made that this situation isn't encountered often and that
one should limit the number of requests per test case, but I still think the
parameter leaking is an unexpected side-effect.
|
|\ \
| |/
|/|
| | |
Fix keyed defaults with root
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The merging of the 'defaults' option was moved up the stack in e852daa
This allows us to see where these options originate from the standard
HttpHelpers (get, post, patch, put, delete)
Unfortunately this move didn't incorporate the 'root' method, which has
always allowed the same 'defaults' option before.
|
| | |
|
| |
| |
| |
| | |
Fixes #25926
|
| | |
|
|/ |
|
| |
|
|
|
|
|
|
|
|
| |
Check for any non-UTF8 characters in path parameters at the point they're
set in `env`. Previously they were checked for when used to get a controller
class, but this meant routes that went directly to a Rack app, or skipped
controller instantiation for some other reason, had to defend against
non-UTF8 characters themselves.
|
|\
| |
| |
| |
| | |
greysteil/dont-raise-unknown-http-method-low-in-stack
Don't raise ActionController::UnknownHttpMethod from ActionDispatch::Static
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The `ActionDispatch::Static` middleware is used low down in the stack to serve
static assets before doing much processing. Since it's called from so low in
the stack, we don't have access to the request ID at this point, and generally
won't have any exception handling defined (by default `ShowExceptions` is added
to the stack quite a bit higher and relies on logging and request ID).
Before https://github.com/rails/rails/commit/8f27d6036a2ddc3cb7a7ad98afa2666ec163c2c3
this middleware would ignore unknown HTTP methods, and an exception about these
would be raised higher in the stack. After that commit, however, that exception
will be raised here.
If we want to keep `ActionDispatch::Static` so low in the stack (I think we do)
we should suppress the `ActionController::UnknownHttpMethod` exception here,
and instead let it be raised higher up the stack, once we've had a chance to
define exception handling behaviour.
This PR updates `ActionDispatch::Static` so it passes `Rack::Request` objects to
`ActionDispatch::FileHandler`, which won't raise an
`ActionController::UnknownHttpMethod` error. If an unknown method is
passed, it should exception higher in the stack instead, once we've had a
chance to define exception handling behaviour.`
|
|\ \
| | |
| | |
| | |
| | | |
javan/fix-namespaced-implicit-render-etag-template-digest
Fix adding implicitly rendered namespaced template digests to ETags
|
| |/ |
|
|\ \
| |/
|/| |
Let TestResponse assign a parser.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously we'd only assign a response parser when a request came through
Action Dispatch integration tests. This made calls to `parsed_body` when a TestResponse
was manually instantiated — though own doing or perhaps from a framework — unintentionally
blow up because no parser was set at that time.
The response can lookup a parser entirely through its own ivars. Extract request encoder to
its own file and assume that a viable content type is present at TestResponse instantiation.
Since the default response parser is a no-op, making `parsed_body` equal to `body`, no
exceptions will be thrown.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Rack [recently](https://github.com/rack/rack/commit/7e7a3890449b5cf5b86929c79373506e5f1909fb)
moved the namespace of its `ParameterTypeError` and `InvalidParameterError`
errors. Whilst an alias for the old name was added, the logic in
`ActionDispatch::ExceptionWrapper` was still broken by this change, since it
relies on the class name.
This PR updates `ActionDispatch::ExceptionWrapper` to handle the Rack 2.0
namespaced errors correctly. We no longer need to worry about the old names,
since Rails specifies Rack ~> 2.0.
|
|\ \
| |/
|/| |
Stop changes to a dupped `ActionController::Parameters` mutating the original
|
| |
| |
| |
| |
| |
| | |
`#initialize_copy` to manually duplicate the underlying parameters hash
It looks like `ActionController::Parameters#dup` is leftover from when the class inherited from `Hash`. We can just trust `#dup`, which already copies the `@permitted` instance variable (confirmed by tests). We still define a `#initialize_copy` to make `@parameters` a copy that can be mutated without affecting the original instance.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When `ActionController::Parameters` is duplicated with `#dup`, it doesn't create a duplicate of the instance variables (e.g. `@parameters`) but rather maintains the reference (see <http://ruby-doc.org/core-2.3.1/Object.html>). Given that the parameters object is often manipulated as if it were a hash (e.g. with `#delete` and similar methods), this leads to unexpected behaviour, like the following:
```
params = ActionController::Parameters.new(foo: "bar")
duplicated_params = params.dup
duplicated_params.delete(:foo)
params == duplicated_params
```
This fixes the bug by defining a private `#initialize_copy` method, used internally by `#dup`, which makes a copy of `@parameters`.
|
| |
| |
| |
| | |
it false
|
|/
|
|
| |
`config.ssl_options` permits configuring various options for the middleware. Default options for HSTS (specified with the `:hsts` key in the options hash) are specified in `.default_hsts_options`. The documentation did not make clear these defaults, and in one case was wrong.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In Rails 4 these kind of routes used to work:
```ruby
scope '/*id', controller: :builds, as: :build do
get action: :show
end
```
But since 1a830cbd830c7f80936dff7e3c8b26f60dcc371d, routes are only created for
paths specified as strings or symbols. Implicit `nil` paths are just ignored,
with no deprecation warnings or errors. Routes are simply not created. This come
as a surprise for people migrating to Rails 5, since the lack of logs or errors
makes hard to understand where the problem is.
This commit introduces a deprecation warning in case of path as `nil`, while
still allowing the route definition.
|
| |
|
|\
| |
| | |
ActionDispatch::DebugLocks
|
| |
| |
| |
| |
| | |
Only intended to be enabled when in use; by necessity, it sits above any
reasonable access control.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When an exception is raised, those Action View rendering logs are just
noise for the end developer. I recently silenced those from Web Console,
as we do use Action View rendering in it as well. It used created a half
a screen of rendering logs. I think we can save those in this recent
push for cleaner development logs.
Now, the silencing is a bit hacky and we have a bunch of it now, so we
can also invest in turning off the logs directly from Action View
objects instead of silencing off the logging stream.
|
| |
| |
| |
| |
| |
| | |
Felt that += overwriting the path variable was a little too hidden.
Make the outcomes easier to spot with an if-else branch.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When running tests with `--enable-frozen-string-literal` or
`# frozen_string_literal: true`, it's currently attempted to mutate the path
string in order to append the format, causing a `RuntimeError`.
```ruby
get '/posts', as: :json
```
```
RuntimeError:
can't modify frozen String
```
This commit fixes the problem by replacing the mutation with a concatenation,
returning a new string.
|
| | |
|
| | |
|
|\ \
| | |
| | | |
Fix setting route's to in a scope
|
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes #25488
97d7dc4 introduced a regression that resulted in ArgumentError when to
was in options of the scope and not of particular route.
|
|/ /
| |
| |
| | |
Signed-off-by: Jeremy Daer <jeremydaer@gmail.com>
|
| |
| |
| |
| | |
Then just yield the location for the place where we need some extra processing.
|
| |
| |
| |
| | |
`if !var.nil?` is the same as just `if var`
|