Date | Commit message (Collapse) |
|
unicorn lost the hijack_setup method in version 5,
so we must recreate it ourselves.
|
|
Unicorn 5 removes some constants we were using, and constant
lookups + inline caching are waste of time anyways on newer
Rubies with the opt_str_freeze bytecode instruction.
This may reduce performance for folks on older Rubies (probably
not noticeable); but improves performance for folks on newer
Rubies.
|
|
Applications may want to alter the message associated with HTTP
status codes in Rack::Utils::HTTP_STATUS_CODES. Avoid memoizing
status lines ahead-of-time
Note: this introduces a minor performance regression, but ought to
be unnoticeable unless you're running "Hello world"-type apps.
|
|
Whatever compatibility reasons which existed in 2009 likely do not exist
now. Other servers (e.g. thin, puma) seem to work alright without it,
so there's no reason to waste precious bytes.
|
|
This will allow us use the sendfile syscall under Linux on
Ruby which favor #read/#readpartial methods for non-IO objects.
This also allows us to revert changes made in
commit db790ff3531acdfa23ab290998bba29360a6782b
("sync_close: This fix breakage from Ruby-trunk r50118")
|
|
Not all responses are seekable, so do not attempt to pass seek
arguments to them since Ruby may attempt to seek (and fail!).
|
|
This requires Rack 1.5.x and unicorn 4.6.0 for hijacking
support. Older versions of Rack continue to work fine,
but we must use unicorn 4.6.0 features to support this.
|
|
It hasn't been used in a while, but we kept it for
Zbatery version compatibility.
|
|
Rack::File already sets Content-Range, so don't repeat work
and reparse Content-Length.
|
|
This allows using IO::Splice.copy_stream from the "io_splice"
RubyGem on recent Linux systems. This also allows users to
disable copy_stream usage entirely and use traditional
response_body.each calls which are compatible with all Rack
servers (to workaround bugs in IO.copy_stream under 1.9.2-p180).
|
|
There's actually no reason we can't have these methods
in Rainbows::Configurator where it's easier to document
nowadays.
|
|
IO#trysendfile does not raise exceptions for common EAGAIN
errors, making it far less expensive to use with the following
concurrency models:
* Coolio
* CoolioFiberSpawn
* Revactor
* FiberSpawn
* FiberPool
This requires the new sendfile 1.1.0 RubyGem and removes support
for the sendfile 1.0.0. All sendfile users must upgrade or be
left without sendfile(2) support. IO#sendfile behaves the same
if you're using a multi-threaded concurrency option, but we
don't detect nor use it unless IO#trysendfile exists.
|
|
We guarantee the Rack env will exist for the duration of
the request/response cycle, so we can just tweak
"rainbows.autochunk".
|
|
Rack::Lint already stops apps from using it. If a developer
insists on it, then users who inspect their HTTP headers can
point and laugh at them for not using Rack::Lint!
|
|
We already set a Status: header by default for compatibility
with some existing, broken libraries out there.
|
|
Reading headers is common and we don't want to create new String
objects (even if they're tiny or copy-on-write) for the GC to
munch on.
|
|
Easier just to use an instance variable
|
|
Believe it or not, Time#httpdate showed up at the top
of my profiler output for the past couple of years now.
I guess that's what happens when all HTTP applications
I write are less complex than Rack::Lobster :P
|
|
HeaderHash is quite expensive, and Rack::File currently
uses a regular Ruby Hash with properly-cased headers the
same way they're presented in rfc2616.
|
|
416 responses without a body should respond with a zero
Content-Length and a Content-Range that allows clients
to specify a proper range in the future.
rfc2616, section 14.16 says:
> A server sending a response with status code 416 (Requested
> range not satisfiable) SHOULD include a Content-Range field
> with a byte-range- resp-spec of "*". The instance-length
> specifies the current length of the selected resource.
|
|
Rack::Utils::HeaderHash is still very expensive in Rack 1.2,
especially for simple things that we want to run as fast as
possible with minimal interference. HeaderHash is unnecessary
for most requests that do not send Content-Range in responses.
|
|
This lets us simplify repetitive checks worry less about
properly maintaining/closing client connections for each
concurrency model we support.
|
|
Use a consistent "Client" naming to reduce confusion
|
|
Although this behavior is mentioned on the documentation,
this was broken under EventMachine, Rev*, and Revactor.
Furthermore, we set the "Connection: close" header to allow the
client to optimize is handling of non-keepalive connections.
|
|
Due to the synchronous nature of Revactor, we can
be certain sendfile won't overstep the userspace
output buffering done by Rev.
|
|
It's a destructive method, and it does more than just parsing.
|
|
The FileStreamer class of EventMachine (and by extension
NeverBlock) unfortunately doesn't handle this. It's possible
to do with Revactor (since it uses Rev under the covers),
but we'll support what we can easily for now.
|
|
This will give each concurrency model more control over
particular code paths and serving static files.
|
|
Since we suck at building websites, we just rely on RDoc as a
website builder. And since Rainbows! is an application server
(and not a programming library), our internal API should be of
little interest to end users.
Anybody interested in Rainbows! (or any other project) internals
should be reading the source.
|
|
Cramp monkey patches Rainbows internals for WebSockets
support and we forgot about it. Add a new integration
test to ensure this continues to work in the future
(and force us to update the test for newer Cramp).
|