| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
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.
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
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.
|
|/ / / / / / |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
People should be free to mutate the header object, but not to set a new
header object. That header object may be specific to the webserver, and
we need to hide it's internals.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
this way we don't have to mutate the instance (as much) when writing a
rack response
|
| | | | | | |
|
| | | | | | |
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
ActionDispatch::SSL should keep original header's behavior
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
`ActionDispatch::SSL` changes headers to `Hash`.
So some headers will be broken if there are some middlewares
on ActionDispatch::SSL and if it uses `Rack::Utils::HeaderHash`.
|