| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
`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.
|
| | |
| | |
| | |
| | | |
It is already on Active Support
|
|\ \ \
| | | |
| | | | |
Replace `ActiveSupport::Concurrency::Latch` with `Concurrent::CountDownLatch` from concurrent-ruby.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The concurrent-ruby gem is a toolset containing many concurrency
utilities. Many of these utilities include runtime-specific
optimizations when possible. Rather than clutter the Rails codebase with
concurrency utilities separate from the core task, such tools can be
superseded by similar tools in the more specialized gem. This commit
replaces `ActiveSupport::Concurrency::Latch` with
`Concurrent::CountDownLatch`, which is functionally equivalent.
|
|\ \ \ \
| | | | |
| | | | | |
Change AC::TestResponse to AD::TestResponse
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
ActionController::TestResponse was removed in d9fe10c and caused a test
failure on Action View as its test case still refers to it.
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | | |
We want to treat the response object as if it's a real response object
(not a test object), so we should only call methods that are on the
superclass.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|