| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
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 use rack-test's upload file objects on the test side so that
we will be able to correctly generate mime blob posts in the future
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Variants are typically set in the controller based on some attribute of
the request that the browser sent. We should make our tests more in
line with reality by doing the same and not mutating the request object.
|
|
|
|
|
| |
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 %>' } }
|
|\ \
| | |
| | | |
Fix the random caching test failure. (Take two)
|
| | | |
|
|/ /
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Using `assert_predicate` and `assert_match` instead of just `assert` is
preferrable because better error messages are output.
In the case of `assert response.cookies.empty?` the error message was
`Failed assertion, no message given.` but now with `assert_predicate` it
will be `Expected {"user_name"=>"david"} to be empty?.`
For `assert_match(/user_name=david/,
response.headers["Set-Cookie"])` as well, the message returned was
unhelpful - `Failed assertion, no message given.` but now will tell what
was expected and what was returned with `Expected /user_name=david/ to
match "user_name=nope; path=/".`
|
|\ \
| | |
| | | |
Allow default_render to take a block to customize behavior when there's no template
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In 0de4a23 the behavior when there is a missing template was changed to
not raise an error, but instead head :no_content. This is a breaking
change and some gems rely on this happening.
To allow gems and other code to work around this, allow
`default_render` to take a block which, if provided, will
execute the contents of that block instead of doing the `head :no_content`.
|
|\ \ \
| | | |
| | | | |
Remove mistaken end from controller_path doc [ci skip]
|
| | |/
| |/| |
|
|\ \ \
| |/ /
|/| | |
Respect routing precedence for HEAD requests
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes the issue described in #18764 - prevents Rack middleware from
swallowing up HEAD requests that should have been matched by a
higher-precedence `get` route, but still allows Rack middleware to
respond to HEAD requests.
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | | |
vngrs/strong_parameters_unpermitted_parameters_wrong_doc_fix
Fix the documentation about ActionController::UnpermittedParameters [ci skip]
|
|/ / / |
|
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 0b3397872582f2cf1bc6960960a6393f477c55e6, reversing
changes made to 56d52e3749180e6c1dcf7166adbad967470aa78b.
As pointed out on the PR, this will hide development mistakes too, which
is not ideal.
|
|\ \
| | |
| | | |
Catch InvalidURIError on bad paths on redirect.
|
| | |
| | |
| | |
| | |
| | | |
Handle URI::InvalidURIError errors on the redirect route method, so it
wont raise a 500 if a bad path is given.
|
|/ / |
|