| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|/ / /
| | |
| | |
| | |
| | |
| | | |
We should disconnect `array_of_permitted_scalars_filter` from the
instance so that we can make hash filtering functional. For now, pull
the conditional up out of that method
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
`ActionController::Parameters#to_h` returns a hash, so lets have
`ActionController::Parameters#to_unsafe_h` return a hash instead of
an `ActiveSupport::HashWithIndifferentAccess` for consistency.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | |
| | |
| | |
| | | |
Rack [already implements `redirect?` on the response object](https://github.com/rack/rack/blob/1569a985e17d9caaf94d0e97d95ef642c4ab14ba/lib/rack/response.rb#L141) so we don't need to implement our own.
|
| | |
| | |
| | |
| | |
| | | |
ActionController::TestResponse was removed in d9fe10c and caused a test
failure on Action View as its test case still refers to it.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | | |
[ci skip] docs: making clear that perform_caching has a limited impact
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
Removed usage line docs [ci skip]
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Concurrent load interlock (rm Rack::Lock)
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We can't actually lean on Rack::Lock's implementation, so we'll just
copy it instead. It's simple enough that that's not too troubling.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We don't need to fully disable concurrent requests: just ensure that
loads are performed in isolation.
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
PATH_INFO is already set, so this branch will never execute.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
we were already generating a path in the previous code (it was just not
returned), so lets just use the already computed path to popluate the
PATH_INFO header
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Since we only work with new instances, these ivars will not be set.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We should call the setter on `path_parameters` so that we know the hash
will only contain the values that we've set.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
I'd like to put all env mutations together so we can understand how to
change this code to call `call` on the controller
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Since parameters are converted to a query string, they will
automatically be turned in to strings by the query parser
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
non_path_parameters is used internally (it never escapes this method) so
we should be able to safely use a regular hash.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
since we are serializing parameters, we don't need to do all the dup
checks on each object.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We should roundtrip the parameters through their respective encoders /
decoders so that the controller will get parameters similar to what they
actually get in a real world situation
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
pass in the instance variable to start decoupling the meat of the parser
from the instance of the middleware
|
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | | |
We will always make an assignment to the env hash and eliminate a
conditional
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
If we only deal with proc objects, then we can eliminate type checking
in the parameter parsing middleware
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We should assign parameters to the request object rather than mutate the
hash that is returned by `query_parameters` or `request_parameters`
|
| | | | |
| | | | |
| | | | |
| | | | | |
this prevents mutations from being available globally
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We should leverage the request / response objects that the superclass
has already allocated for us.
|
| | | | | |
|
|/ / / /
| | | |
| | | |
| | | |
| | | | |
There is no reason to "recycle" response objects when we can just
allocate a new one.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
we should be pushing the cookies in via headers rather than maintaining
some object and "recycling" it.
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
Allow filtering params based on parent keys
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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 %>' } }
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This change decouples `cookie_jar` allocation from the request object.
We need this for moving controller tests to integration tests so we can
access the `cookie_jar` object separately.
|
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This sort of documentation style comes from 2009, probably due to
the merging of merb (see https://github.com/rails/rails/commit/38b608ecab2441cd0c4e75bc08bdf57fcf85dd71#diff-017d9bc9b1d2bdae199b938d72c15488R120).
Rails follows Ruby's convention to define which values are "truthy" or
"falsey", so there is no need to specify that the returned value must
strictly be a TrueClass or FalseClass. /cc @fxn
|
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Clarify the `url_for` usage in mailers.
Re-add the documentation about `url_for` and Route's path parameters,
first introduced by 5c4f1859970d06228a0b67cad6d4486c1526ef2a.
This was reported on #15097 and until it is decided to deprecate it
or not, I believe the documentation should exist.
|