| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The following Rails code failed (with a `KeyError` exception) under
test:
```ruby
class ApplicationController < ActionController::Base
def user_strategy
# At this point:
# ```ruby
# session == {
# "user_strategy"=>"email",
# "user_identifying_value"=>"hello@world.com"
# }
# ```
if session.key?(:user_strategy)
session.fetch(:user_strategy)
end
end
end
```
When I checked the session's keys (`session.keys`), I got an array of
strings. If I accessed `session[:user_strategy]` I got the expected
`'email'` value. However if I used `session.fetch(:user_strategy)` I
got a `KeyError` exception.
This appears to be a Rails 4.2.4 regression (as the code works under
Rails 4.2.3).
Closes #21383
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Rack::Response::Helpers implements this method, so we can safely remove
it
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
If the response method is defined, then calling `response` will return a
response.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
If AV::Rendering is mixed in, then `rendered_format` will be calculated
based on the current `lookup_context`, but calling `_process_format`
will set the `rendered_format` back on to the same lookup context where
we got the information in the first place!
Instead of getting information from an object, then setting the same
information back on to that object, lets just do nothing instead!
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Apparently the AbstractController (whatever "abstract" means) is
expected to work without a request and response.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
`render` is the only possible source for the `plain` option. Pulling
the conditional up to the `render` method removes far away conditionals
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We don't need to pass the full hash just to pull one value out. It's
better to just pass the value that the method needs to know about so
that we can abstract it away from "options"
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Since all controller instances are required to have a request and
response object, RackDelegation is no longer needed (we always have to
delegate to the response)
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
the subclass sets the body on the response object, so we don't need the
superclass doing it too
|
| | | | |
| | | | |
| | | | |
| | | | | |
without this module, the content type is not set correctly
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Now that `Controller#status=` just delegates to the response object,
we don't need to set the response on the controller and the response.
We can just set it in one place.
|
| | | | |
| | | | |
| | | | |
| | | | | |
we always have a response object, so there is no reason to test it
|
| | | | |
| | | | |
| | | | |
| | | | | |
these ivars don't exist anymore, so we can remove them from the list
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
since the controller always has a request on it, we can just ask the
request for the content type.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The controller instance always has an instance of a response object. We
should store the status code on the response object so that it's only
store in one place.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We always have a response object in controller instances, so we can
remove this conditional
|
|/ / / /
| | | |
| | | |
| | | |
| | | | |
controller instances always have a response object, so we don't need to
test to see if there is one, just always call to_a on the response.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Controllers should always have a request and response when responding.
Since we make this The Rule(tm), then controllers don't need to be
somewhere in limbo between "asking a response object for a rack
response" or "I, myself contain a rack response". This duality leads to
conditionals spread through the codebase that we can delete:
* https://github.com/rails/rails/blob/85a78d9358aa728298cd020cdc842b55c16f9549/actionpack/lib/action_controller/metal.rb#L221-L223
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
we don't need an instance to figure out what type of response to
allocate. Later we'll pull this up the stack and pass the response
object down
|
| | | |
| | | |
| | | |
| | | | |
This saves a lambda and request allocation on each request.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
controllers should always go through the `action` class method so that
their middleware is respected.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
now the caller can just treat it like a regular controller even though
it will return a 404
|
| | | |
| | | |
| | | |
| | | | |
They are already required in `actionpack/lib/action_dispatch.rb` (L25-L26)
|
| | | |
| | | |
| | | |
| | | |
| | | | |
This `protected` keyword looks like some leftover, since
we are not using explicit receiver, this should go under `private`
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
We don't want to directly access the env hash
|
| | | |
| | | |
| | | |
| | | |
| | | | |
I want to implement this with something besides `@env` in the future, so
lets stop directly referencing it.
|
| | | |
| | | |
| | | |
| | | | |
superclass already has this method, so remove this one
|
| | | |
| | | |
| | | |
| | | |
| | | | |
the dispatcher class isn't configurable anymore, so pull up allocation
to the method that needs it.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Now that we don't have subclasses depending on this method (they augment
the request class instead of the dispatch class) we can remove this
method and directly ask the request object for the controller class
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
we don't need it anymore. We always use the same dispatcher in tests.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
controller class resolution has been moved to the request object, so we
should override that method instead of relying on the RouteSet to
generate the controller class.
|
|\ \ \ \
| | | | |
| | | | | |
Remove unused block arguments
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
we already have a request, so we should use the methods on the request
to access the path info information
|
| | | | |
| | | | |
| | | | |
| | | | | |
Creates fewer request objects and helps to abstract away from internals
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
try to remove dependencies on `@env` so we can have more flexible
internals
|