| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by Active Support)
Selecting which key extensions to include in active_support/rails
made apparent the systematic usage of Object#in? in the code base.
After some discussion in
https://github.com/rails/rails/commit/5ea6b0df9a36d033f21b52049426257a4637028d
we decided to remove it and use plain Ruby, which seems enough
for this particular idiom.
In this commit the refactor has been made case by case. Sometimes
include? is the natural alternative, others a simple || is the
way you actually spell the condition in your head, others a case
statement seems more appropriate. I have chosen the one I liked
the most in each case.
|
| |
|
|\
| |
| |
| |
| |
| | |
Conflicts:
activemodel/lib/active_model/secure_password.rb
activerecord/lib/active_record/associations/collection_proxy.rb
|
| |
| |
| |
| | |
HTTP Token authentication in integration tests
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
single check.
Rails includes a single character body to a head(:no_content) response to work around an old Safari bug where headers were ignored if no body sent.
This patch brings the behavior slightly closer to spec if :no_content/204 is explicity requested via a head only response.
Status comparison done on symbolic and numeric values
Not returning any content when responding with head and limited to a status code that explicitly states no content will be returned - 100..199, 204, 205, 304.
|
|\ \
| | |
| | | |
Fix for digest authentication bug - issue #2301 in rails/rails
|
| | | |
|
| | | |
|
| | | |
|
|/ / |
|
|\ \
| | |
| | | |
Follow code conventions in metal/live
|
| | | |
|
|/ / |
|
| | |
|
| |
| |
| |
| | |
will work
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
responses.
Processing controller actions in a separate thread allows us to work
around the rack api - we can allow the user to set status and headers,
then block until the first bytes are written. As soon as the first
bytes are written, the main thread can return the status, headers, and
(essentially) a queue for the body.
|
| | |
|
| | |
|
|/
|
|
|
| |
Conflicts:
actionpack/lib/action_controller/metal/http_authentication.rb
|
| |
|
|
|
|
|
| |
- #respond_to's documentation refer to .respond_to, but it was
written as just <respond_to>. Added class name for clarification.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When someone sends malformed authorization header, like:
Authorization: Token foobar
given token should be just ignored and resource should not be authorized,
instead of raising error. Before this patch controller would return 401 header
only for well formed tokens, like:
Authorization: Token token=foobar
and would return 500 in former case.
|
|\ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
merging cookies is responsibility of the test runner
|
| |
| |
| |
| |
| |
| | |
For some reason, this special logic is only supposed to be executed on
the second request. For now, we'll extend on recycle, but we should
figure out why this functionality can't be run on every request
|
| |
| |
| |
| |
| | |
Try to avoid making the controller mutate itself so that we can
eventually make the response async
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this patch the existing .force_ssl method handles both defining
the filter and handling the logic for performing the redirect.
With this patch the logic for redirecting to the HTTPS protocol is
separated from the filter logic that determines if a redirect should
occur. By separating the two levels of behavior, an instance method
for ActionController (i.e. #force_ssl_redirect) is exposed and available
for more granular SSL enforcement.
Cleaned up indentation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When more than one directory for helpers is provided to a controller, it
should preserver the order of directories. Given 2 paths:
MyController.helpers_paths = ["dir1/helpers", "dir2/helpers"]
helpers from dir1 should be loaded first. Before this commit, all
helpers were mixed and then sorted alphabetically, which essentially
would require to rename helpers to get desired order.
This is a problem especially for engines, where you would like to be
able to predict accurately which engine helpers will load first.
(closes #6496)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently Rack raises a TypeError when it encounters a malformed or
ambiguous hash like `foo[]=bar&foo[4]=bar`. Rather than pass this
through to the application this commit captures the exception and
re-raises it using a new ActionController::BadRequest exception.
The new ActionController::BadRequest exception returns a 400 error
instead of the 500 error that would've been returned by the original
TypeError. This allows exception notification libraries to ignore
these errors if so desired.
Closes #3051
|