| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
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 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=/".`
|