| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because it is more natural way to test substring inclusion. Also, in
this particular case it is much faster.
In general, using `Regexp.new str` for such kind of things is dangerous.
The string must be escaped, unless you know what you're doing. Example:
Regexp.new "\\" # HELLO WINDOWS
# RegexpError: too short escape sequence: /\/
The right way to do this is escape the string
Regexp.new Regexp.escape "\\"
# => /\\/
Here is the benchmark showing how faster `include?` call is.
```
require 'benchmark/ips'
Benchmark.ips do |x|
x.report('include?') { !"index".to_s.include? File::SEPARATOR }
x.report(' !~ ') { "index" !~ Regexp.new(File::SEPARATOR) }
end
__END__
Calculating -------------------------------------
include? 75754 i/100ms
!~ 21089 i/100ms
-------------------------------------------------
include? 3172882.3 (±4.5%) i/s - 15832586 in 5.000659s
!~ 322918.8 (±8.6%) i/s - 1602764 in 4.999509s
```
Extra `.to_s` call is needed to handle the case when `action_name` is
`nil`. If it is omitted, some tests fail.
|
| | |
|
| |\
| |
| | |
Change Http::Cache::SPECIAL_KEYS from Array to Set
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Slightly improves performance, for example, a simple benchmark:
```ruby
require 'benchmark/ips'
require 'set'
SPECIAL_KEYS = %w[extras no-cache max-age public must-revalidate]
SPECIAL_KEYS_SET = Set.new(SPECIAL_KEYS)
directive = 'must-revalidate'
Benchmark.ips do |x|
x.report('array') { SPECIAL_KEYS.include?(directive) }
x.report('set') { SPECIAL_KEYS_SET.include?(directive) }
end
```
Output:
```
-------------------------------------
array 67926 i/100ms
set 74054 i/100ms
-------------------------------------
array 2318423.4 (±2.8%) i/s - 11615346 in 5.014899s
set 3387981.8 (±4.7%) i/s - 16958366 in 5.019355s
```
|
| |\ \
| | |
| | | |
Remove unused parameter.
|
| | |/ |
|
| |/ |
|
| |
|
|
| |
Fixes issue #15511.
|
| |\
| |
| |
| | |
ActionController::Parameters#require now accepts FalseClass values
|
| |/
|
|
| |
Fixes #15685.
|
| |\
| |
| | |
Set flash in test session when necessary.
|
| | |
| |
| |
| | |
`to_session_value` returns nil when empty.
|
| | | |
|
| |/
|
|
|
|
|
| |
The 401 status should be set first because setting the response body in
a live controller also closes the response to further changes.
Fixes #14229.
|
| | |
|
| |
|
|
|
| |
if the subdomain wasn't specified, it's the same as if specifying
:subdomain as `true`, so we can default the value to `true` safely.
|
| | |
|
| |
|
|
|
| |
`normalize_host` already calls `named_host?`, so there is no reason to
test `named_host?` again in the `extract_domain` method.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Before:
/Users/Juan/dev/rails/actionpack/lib/action_dispatch/http/url.rb:95: warning: shadowing outer local variable - port
After:
No warning
|
| |
|
|
|
| |
extract_subdomain always returns a string, and to_param calls to_s on a
string
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
irb(main):004:0> /foo/ !~ nil
=> true
irb(main):005:0> /foo/ !~ 'bar'
=> true
irb(main):006:0> /foo/ !~ 'foo'
=> false
|
| |
|
|
|
| |
remove the default parameter since the methods are always called with a
parameter
|
| | |
|
| |
|
|
| |
This reverts commit 79469b4b0c05a50e19699bc9b568042add2d4987.
|
| | |
|
| |\
| |
| | |
remove warnings
|
| | |
| |
| |
| | |
warning: assigned but unused variable - scope_called, path and strexp
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |\
| |
| | |
Restore test deliveries for ActionMailer.
|
| | | |
|
| | |
| |
| |
| | |
.. even when the producer is blocked for a write.
|
| | | |
|
| | |
| |
| |
| | |
This is a regression test for 29844dd.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We cannot cache keys because arrays are mutable. We rather want to cache
the arrays. This behaviour is tailor-made for the usage pattern strongs
params is designed for.
In a forthcoming commit I am going to add a test that covers why we need
to cache by value.
Every strong params instance has a live span of a request, the cache goes
away with the object. Since strong params have such a concrete intention,
it would be interesting to see if there are actually any real-world use
cases that are an actual leak, one that practically may matter.
I am not convinced that the theoretical leak has any practical consequences,
but if it can be shown there are, then I believe we should either get rid of
the cache (which is an optimization), or else wipe it in the mutating API.
This reverts commit e63be2769c039e4e9ada523a8497ce3206cc8a9b.
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
| |
Also expand the CGI_VARIABLE name listing to multiple lines for cleaner diffs and legibility.
|
| |
|
| |
Per convention, underscore-only argument names should be used for unused parameters.
|
| |\
| |
| | |
Reset callbacks after test.
|
| | |
| |
| |
| | |
Otherwise the state of callback chain is leaked.
|
