| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
| |
Briefly mention all middleware that ship with Rack.
Mention that you should require rack and not paths under rack.
|
|
|
|
|
|
|
|
|
| |
The previous behavior was broken if a middleware modified any
part of the response.
Modify the logic slightly to use an early return instead of just
breaking out of the loop, which should be faster in the general
case.
|
| |
|
|
|
|
|
|
| |
This was added due to issue #434, but the links in that issue
make clear it is only needed in Ruby <1.9.3. As Ruby 2.3+ is
now required, this should be safe to remove.
|
|
|
|
|
| |
This doesn't work if you define respond_to?, but does work if
you define respond_to_missing?.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The purpose of the `File.join` is to deal with redundant slashes for example
```
File.join("foo/", "bar")
# => "foo/bar"
```
In this case we are guaranteed that there will be not slashes in our data because we are first splitting by separators:
```
parts = path_info.split PATH_SEPS
```
We can speed up this call then by using the `Array#join` method which does less work:
```
require 'benchmark/ips'
SOURCE_ARRAY = ["foo", "bar"]
Benchmark.ips do |x|
x.report("Array#join") do |times|
i = 0
while i < times
SOURCE_ARRAY.join(::File::SEPARATOR)
i +=1
end
end
x.report("File#join") do |times|
i = 0
while i < times
::File.join(SOURCE_ARRAY)
i +=1
end
end
x.compare!
end
```
You can see this method of building strings is roughly 2.55 times faster than the current method
```
Warming up --------------------------------------
Array#join 111.966k i/100ms
File#join 62.000k i/100ms
Calculating -------------------------------------
Array#join 2.075M (±12.1%) i/s - 10.189M in 5.022957s
File#join 813.613k (±11.5%) i/s - 4.030M in 5.052667s
Comparison:
Array#join: 2075017.5 i/s
File#join: 813613.1 i/s - 2.55x slower
```
|
| |
|
|
|
|
| |
JRuby may execute the trap in parallel.
|
|
|
|
| |
Also, fix the require in one of the stackprof tests.
|
| |
|
| |
|
|
|
|
| |
3378 / 3378 LOC (100.0%) covered
|
|
|
|
|
|
|
|
| |
The previous code to do this was broken, since it modified a
local variable and not the actual response headers. Note that
this checking can only be done if the response headers are a
hash, as this requires modifying the response headers, so it
is only done in that case.
|
|
|
|
| |
3352 / 3378 LOC (99.23%) covered
|
|
|
|
| |
3332 / 3380 LOC (98.58%) covered.
|
|
|
|
| |
3316 / 3380 LOC (98.11%) covered
|
|
|
|
|
| |
Fixes a bug when in invalid handler is used and -h is also used.
That now prints appropriate help. Previously, you got a backtrace.
|
| |
|
|
|
|
|
|
|
| |
Coverage testers may not have the related libraries for these
handlers installed.
3219 / 3381 LOC (95.21%) covered.
|
|
|
|
| |
Currently: 3352 / 3602 LOC (93.06%) covered
|
|
|
|
|
|
|
|
|
| |
This can only be hit if filename is nil/false. However, when
the MimePart is created, it is either a TempfilePart if there
is a filename or a BufferPart otherwise. In the TempfilePart
case, the filename is present so this code is not hit. In the
BufferPart case, the body is a String and not an IO, so this
cannot be hit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before, @length was always set to 0 in the constructor. The breaks
the case where a string was provided, since that is automatically
bufferred. Fix that by using the bytesize of the string.
If body was provided as an array, when switching to buffered mode,
iterate over the body to figure out the content length.
Note this only occurs when doing Response#write, as that is the
only case where Response updates the Content-Length.
I found one spec that called Response#write inside a Response#finish
block. That updates the response body after the header hash is
returned, and does not call Response#append as the @writer has been
changed to the Response#finish block, so it doesn't update the
Content-Length in the returned header hash.
|
|
|
|
|
|
| |
module_function with no arguments operates similar to public or
private, making all methods defined after it in scope module
functions.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This does a better job of testing the autoloads work, and ensures
files are loaded from the current rack directory.
Some files required rack.rb, and in those cases I didn't remove
the require, just replaced it with require_relative, since the
intent is to make sure all of rack is loaded if a file under
rack is loaded.
This has the potential to break code that does:
require 'rack/content_type'
Rack::ContentType.new(app)
If the rack library itself is never required. This is because
the autoloads that rack.rb sets up would not be loaded. I'm not
sure if we want to support that, but if so we would want to keep
the requires and convert them to require_relative.
For core_ext/regexp, move the requires into the if < 2.4 block,
so that the file isn't loaded unless it is necessary.
|
|
|
|
|
|
| |
For some reason, the test helper was only used by a single spec file.
This uses it for all spec files. While here, rely on autoload
loading the libraries instead of loading everything manually.
|
|
|
|
|
|
| |
I am no fan of autoload, but since it is used for pretty much
everything else, it is best to be consistent and also use it
for these three middleware.
|
| |
|
|
|
|
|
| |
Ruby 2.4+ support Regexp#match? and does not require loading a
refinement.
|
|
|
|
|
|
| |
This is only used in a single place, it is better to use a unified
approach. After Ruby 2.4 support is dropped, we can switch back
stringify_keys back, and avoid the refinement.
|
|
|
|
|
| |
Maintainers should now try to keep CHANGELOG up to date when
committing or after merging pull requests.
|
|
|
|
|
|
| |
This uses separate placeholders for SCRIPT_NAME and PATH_INFO.
Fixes #1070
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the query string is empty, instead of using a plain hash, we
still need to use params.to_params_hash, as params.to_params_hash
may return a different object, such a hash with a default proc.
This fixes request.params in cases where indifferent query
params are used, and r.GET is empty but r.POST is not. Before
this commit, this would result in request.params ending up with
a non-indifferent hash, when it should have used an indifferent
hash.
The cause of this issue can originally be traced to an optimization
in c4596b3e3d821d19b25c2d48d619097a3ad39ec0, which was before I
added the code to allow user-configurable query params in
7e7a3890449b5cf5b86929c79373506e5f1909fb. Now that
user-configurable query params are supported, the optimization is
invalid and needs to be removed.
|
|
|
|
|
|
| |
Simplify options[:require] handling while here.
Fixes #1122
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This is already required by rack's session support, so it should
be in SPEC/Lint.
Add some more rack.session Lint tests while here.
Fixes #461
|
|
|
|
|
|
|
| |
Also, correctly handle deleting with both a domain and path
provided.
Fixes #1234
|
| |
|
|
|
|
| |
A frozen request env would break Rack::Request.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
non-ASCII characters
Fixes warning when binary Regexp is used to match against a
CGI value (QUERY_STRING).
ASCII-8BIT encoding is already required for response bodies.
Requiring this encoding for all CGI values would break usage
with puma and potentially other rack servers. So it seems
safest to only require ASCII-8BIT encoding when the value
actually contains non-ASCII. We could further limit it to
just QUERY_STRING, but I'm not sure we want to do that.
Testing with a few rack servers:
* Unicorn always uses ASCII-8BIT for all CGI values.
* Puma will use UTF-8 for some values, but uses ASCII-8BIT
for CGI values contianing non-ASCII characters.
* Webrick doesn't support non-ASCII chracters, at least for
PATH_INFO or QUERY_STRING.
If we don't do this, the only way to avoid the warning would be
to duplicate QUERY_STRING if it is not already binary. Checking
encoding will slow down parsing even if it already uses
ASCII-8BIT encoding.
Fixes #1183
|
| |
|
|
|
|
| |
This test broke if UTF-8 is not the default_external encoding.
|
|
|
|
|
| |
The behavior changed in the previous commit, but I think it is
better to specify the new behavior versus leaving it unspecified.
|