Date | Commit message (Collapse) |
|
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).
|