Date | Commit message (Collapse) |
|
I don't build IPv6 into all my kernels; maybe other testers do
not, either.
|
|
RFC 2616 doesn't appear to allow most CTL bytes even though
Mongrel always did. Rack::Lint disallows 0..31, too, though we
allow "\t" (HT, 09) since it's LWS and allowed by RFC 2616.
|
|
The random garbage generator may occasionally generate URIs that
are too long and cause the URI-specific error to be raised
instead of the generic parser error we recently introduced.
Follow-up-to: commit 742c4d77f179a757dbcb1fa350f9d75b757acfc7
|
|
rescuing from SystemExit and exit()-ing again is ugly, but
changes made to lower stack depth positively affect _everyone_
so we'll tolerate some ugliness here.
We'll need to disable graceful exit for some tests, too...
|
|
This means we no longer waste an extra file descriptor per
worker process in the master. Now there's no need to set a
higher file descriptor limit for systems running >= 1024
workers.
|
|
The random garbage generator may occasionally generate URIs that
are too long and cause the URI-specific error to be raised
instead of the generic parser error we recently introduced.
Follow-up-to: commit 742c4d77f179a757dbcb1fa350f9d75b757acfc7
|
|
It may return the previous second
|
|
The random garbage generator may occasionally generate URIs that
are too long and cause the URI-specific error to be raised
instead of the generic parser error we recently introduced.
|
|
This allows one to enter the dechunker without parsing
HTTP headers beforehand. Since we skipped header parsing,
trailer parsing is not supported since we don't know
what trailers might be (to our knowledge, nobody uses trailers
anyways)
|
|
Enabling this flag for an IPv6 TCP listener allows users to
specify IPv6-only listeners regardless of the OS default.
This should be interest to Rainbows! users.
|
|
RFC 2616, section 4.2:
> The field-content does not include any leading or trailing LWS:
> linear white space occurring before the first non-whitespace
> character of the field-value or after the last non-whitespace
> character of the field-value. Such leading or trailing LWS MAY be
> removed without changing the semantics of the field value. Any LWS
> that occurs between field-content MAY be replaced with a single SP
> before interpreting the field value or forwarding the message
> downstream.
|
|
|
|
Ugh, one day I'll clean them up, one day...
|
|
for i in `git ls-files '*.rb'`; do ruby -w -c $i; done
|
|
This is much like how nginx does it, except we always require a
port when explicitly binding to IPv6 using the "listen"
directive. This also adds support to listen with an
address-only, which can be useful to Rainbows! users.
|
|
Just in case we have people that don't use DNS, we can support
folks who enter ugly IPv6 addresses...
IPv6 uses brackets around the address to avoid confusing
the colons used in the address with the colon used to denote
the TCP port number in URIs.
|
|
The client may not get a proper response with TCP_CORK enabled
|
|
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!
|
|
Response bodies may capture the block passed to each
and save it for body.close, so don't close the socket
before we have a chance to call body.close
|
|
But allows small optimizations to be made to avoid
constant/instance variable lookups later :)
|
|
No need to preserve the response tuplet if we're just
going to unpack it eventually.
|
|
This can return a static string and be significantly
faster as it reduces object allocations and Ruby method
calls for the fastest websites that serve thousands of
requests a second.
It assumes the Ruby runtime is single-threaded, but that
is the case of Ruby 1.8 and 1.9 and also what Unicorn
is all about. This change is safe for Rainbows! under 1.8
and 1.9.
|
|
It's a minor garbage reduction, but nobody uses "$,", and
if they did, they'd break things in the Ruby standard library
as well as Rack, so let anybody who uses "$," shoot themselves
in the foot.
|
|
We use this in Rainbows! to disable keepalive in certain
configurations.
|
|
We need to preserve our internal flags and only clear them on
HttpParser#parse. This allows the async concurrency models in
Rainbows! to work properly.
|
|
Oops
|
|
More config bloat, sadly this is necessary for Rainbows! :<
|
|
Evil clients may be exposed to the Unicorn parser via
Rainbows!, so we'll allow people to turn off blindly
trusting certain X-Forwarded* headers for "rack.url_scheme"
and rely on middleware to handle it.
|
|
The first value of X-Forwarded-Proto in rack.url_scheme should
be used as it can be chained. This header can be set multiple
times via different proxies in the chain, but consider the first
one to be valid.
Additionally, respect X-Forwarded-SSL as it may be passed with
the "on" flag instead of X-Forwarded-Proto.
ref: rack commit 85ca454e6143a3081d90e4546ccad602a4c3ad2e
and 35bb5ba6746b5d346de9202c004cc926039650c7
|
|
This limits the number of keepalive requests of a single
connection to prevent a single client from monopolizing server
resources. On multi-process servers (e.g. Rainbows!) with many
keepalive clients per worker process, this can force a client to
reconnect and increase its chances of being accepted on a
less-busy worker process.
This directive is named after the nginx directive which
is identical in function.
|
|
This allows apps/middlewares on Rainbows! that rely on env in
the response_body#close to hold onto the env.
|
|
Some apps may do them, so make sure we do them correctly.
|
|
No need to accept any number of args, that could hide bugs in
applications that could give three or more arguments. We also
raise ArgumentError when given a negative length argument to
read.
|
|
Any calls to read with an explicit zero length now returns an
empty string. While not explicitly specified by Rack::Lint,
this is for compatibility with StringIO and IO methods which
are common in other web servers.
|
|
It's possible for an application to call size after it has read
a few bytes/lines, so do not screw up a user's read offset when
consuming input.
|
|
We'll need this in Rainbows!
|
|
We will eventually expose a Unicorn::StreamInput object as
"rack.input" for Rack 2.x applications. StreamInput allows
applications to avoid buffering input to disk, removing the
(potentially expensive) rewindability requirement of Rack 1.x.
TeeInput is also rewritten to build off StreamInput for
simplicity. The only regression is that TeeInput#rewind forces
us to consume an unconsumed stream before returning, a
negligible price to pay for decreased complexity.
|
|
An easy combination of the existing HttpParser#keepalive? and
HttpParser#reset methods, this makes it easier to implement
persistence.
|
|
Yes, this means even POST/PUT bodies may be kept alive,
but only if the body (and trailers) are fully-consumed.
|
|
We cannot clear the buffer between requests because
clients may send multiple requests that get taken in
one read()/recv() call.
|
|
This should be easier for Rainbows! to use
|
|
The parser and request object become one and the
same, since the parser lives for the lifetime
of the request.
|
|
This provides the kgio_read! method which is like readpartial,
only significantly cheaper when a client disconnects on us.
|
|
TeeInput methods may be invoked deep in the stack, so
avoid giving them more work to do if a client disconnects
due to a bad upload.
|
|
It's expensive to generate a backtrace and this exception
is only triggered by bad clients. So make it harder for
them to DoS us by sending bad requests.
|
|
It's a much closer representation of what we'd expect in
the real server than a mono-directional UNIX pipe.
|
|
The bugs from signal handling were fixed in the Rubinius
1.1.0 release.
|
|
This should hopefully make the non-blocking accept()
situation more tolerable under Ruby 1.9.2.
|
|
This should ensure we have less typing to do.
|
|
There's no need for a response class or object since Rack just
uses an array as the response. So use a procedural style which
allows for easier understanding.
We shall also support keepalive/pipelining in the future, too.
|