| Date | Commit message (Collapse) |
|---|
|
We cannot pass trailers from upstreams to HTTP/1.0 clients without
fully-buffering the response body AND trailers before forwarding the
response header.
Of course, one of the reasons yahns exists is to support lazy
buffering, so fully-buffering up front is wasteful and hurts
latency. So instead, degrade to 1.0 requests to upstreams for
HTTP/1.0 clients, this should prevent upstreams from sending
trailers in the first place.
HTTP/1.0 clients on Rails apps may suffer, but there probably
are not too many HTTP/1.0 clients out there.
|
|
Rack apps may (through a round-about way) send HTTP trailers
to HTTP/1.1 clients, and we need a way to forward those responses
through without losing the trailers.
|
|
We need to ensure more uncommon cases such as gigantic upstream
headers and truncated upstream responses are handled properly
and predictably.
|
|
Pipelining uploads is rare in practice, but they must behave
properly in case some brave soul wants to start doing it.
|
|
Even if a response is screwed, we need to ensure breakage is
predictable.
|
|
We were incorrectly stashing the return value of detach_rbuf!
into the inter-thread buffer buffer which is bound to the client.
|
|
This allows our reverse proxy to avoid having an innefficient 1:1
relationship between threads and upstream connections, reducing
memory usage when there are many upstream connections (possibly to
multiple backend machines).
|
|
This should make it easier to track state for asynchronous
proxy_pass buffering.
|
|
This will allow us to write arrays for chunked output without
unnecessary data copies.
|
|
This is no longer a part of the "extras" section
|
|
This will rely on rack.hijack in the future to support
asynchronous execution without tying up a thread when waiting
for upstreams. For now, this allows simpler code with fewer
checks and the use of monotonic time on newer versions of Ruby.
|
|
Of course, some users will prefer to bind HTTP application
servers to Unix domain sockets for better isolation and (maybe)
better performance.
|
|
We probably do not want env["rack.input"] to become unusable
upon hijacking. Only drop the internal reference to it so
it can eventually become garbage-collected, but there's no
point in making env["rack.input"] unreadable.
|
|
Oops, this test bug was introduced in:
commit e413325737f23c5ec27a02246f95077bc1fb038d
("acceptor: close inherited-but-unneeded sockets")
|
|
When inheriting sockets from the parent via YAHNS_FD, we must close
sockets ASAP if they are unconfigured in the child. This bug exists
in yahns (and not unicorn) because of the trickier shutdown routine
we do for blocking accept system calls to work reliably with the
threading support in mainline Ruby 2.x. This bug would not exist
in a purely C server using blocking accept, either.
|
|
This module will probably become an official part of yahns
soon, so finally add tests for this module.
|
|
It may be useful for us to track down potential errors in
our code or log when an upstream misbehaves.
|
|
While 1.9.3 support will probably be kept for another year or so,
it's probably not worth supporting non-critical extras/ stuff on
1.9.3.
|
|
Since we only support 1.9.3+, io.stat.size may be simplified
to io.size to reduce allocations of File::Stat objects.
|
|
We'll be writing more SSL-related tests in the future...
|
|
If we're streaming large files and sendfile fails (due to a
client aborting the connection), we need to ensure middleware
proxies are closed to ensure proper logging of a partial request.
This affects users of the "clogger" gem serving static files.
Unfortunately with clogger (or any Rack API-compliant middleware
using "to_path"), we still cannot log the amount of bytes
transferred for a static file.
|
|
We rely on exception-free non-blocking I/O for performance,
so it is easier for us to avoid supporting new features on
old Rubies.
|
|
The current CA model and code quality of OpenSSL have long put me off
from supporting TLS; however but efforts such as "Let's Encrypt"
and the fallout from Heartbleed give me hope for the future.
This implements, as much as possible, a "hands-off" approach to TLS
support via OpenSSL. This implementation allows us to shift
responsibility away from us to users and upstreams (the Ruby 'openssl'
extension maintainers, software packagers, and OpenSSL project itself).
This is also perhaps the easiest way for now for us, while being most
powerful for users. It requires users to configure their own OpenSSL
context object which we'll use as-is.
This context object is used as the :ssl_ctx parameter to the "listen"
directive in the yahns configuration file:
require 'openssl' # we will not do this for the user, even
ctx = OpenSSL::SSL::SSLContext.new
# user must configure ctx here...
listen 443, ssl_ctx: ctx
This way, in case we support GnuTLS or other TLS libraries, there'll
be less confusion as to what a user is actually using.
Note: this feature requires Ruby 2.1 and later for non-kgio
{read,write}_nonblock(.. exception: false) support.
|
|
No need to waste space on this (and trigger "Bad partial
reference!" warnings on lynx)
|
|
This test is less reliable when there are multiple workers as the
second worker may not be ready to detect a dead parent.
This is still a possible race if the master dies very quicklly
before a worker is fully setup.
|
|
Followup-to commit ade89b5142bedbcf07f38aa062bfdbfcb8bc48d3
("wbuf: hack to avoid response corruption on FreeBSD")
It seems that we cannot test wbuf internals reliably outside of
Linux, however as long as the end result (via HTTP) is unchanged
on other OSes, we seem to be doing OK.
|
|
GC will close redundantly and lead to EBADF when finalizing. This was
probably harmless as the original IO objects remained marked; but do
not count on it. Seeing EBADF in a MT process is a very bad sign
(inadvertant information disclosure is only one race condition away).
Fortunately, this bug was limited to our test suite :)
|
|
There's a feature request for better coverage support in ruby-trunk
https://bugs.ruby-lang.org/issues/9508
At minimum, we need to preserve compatibility; but we should set
aside time to take advantage of the extra coverage support.
|
|
|
|
TCP socket timing is too varied over different OSes, Unix sockets
seem to test more reliably than TCP ones on my Debian GNU/kFreeBSD
system.
|
|
Not all TCP stacks behave the same with timing-sensitive tests.
Fortunately these timing differences aren't very critical over real
networks.
|
|
We may unnecessarily drop persistent connections from this bug,
and we had an incorrect assertion in our unit test, even.
|
|
We must not cork response headers when the response body is empty,
otherwise those headers will be delayed by 200ms.
|
|
If Content-Length is known, try to save some bandwidth by
corking the headers until the body is sendable. This allows
us to avoid sending an extra packet for small HTTP responses.
This allows high-performance websites like YHBT.net to be served
faster!
|
|
ab(1) is less common than our other dependencies, so allow tests
to run without it.
|
|
Leave that up to Rack::Chunked/Rack::ContentLength.
Chunking ourselves interacts badly with Rack::Deflater, since
Deflater will blindly deflate already-chunked portions.
|
|
Some attackers may try /path/to/file/foo where /path/to/file
is actually a valid path to a regular file. Of course, requests
like this work on dynamic websites, but not static file mappings
because Unix directories and files cannot be the same thing.
|
|
ref: https://github.com/rubinius/rubinius/issues/2772
|
|
This was failing under Rubinius and not necessary after all
ref: https://github.com/rubysl/rubysl-io-wait/issues/2
|
|
Following our own advice in
commit a79a6d8775171ad5cceda9bb3a77946ba60e26ce
(doc: recommend worker_processes if the app uses SIGCHLD)
|
|
We can use the wbuf_close return value instead to ensure we close
tmpio properly and follow the same code path as a normal
(:wait_writable-triggering) buffered response would.
Add a few tests to ensure we properly close the response body
for exec_cgi, where I noticed zombies and started me down this
rabbit hole looking for places where the response body was not
closed properly.
|
|
Unlike Rack::Directory, this this also avoids tables and CSS for
preformatted HTML. This is meant to resemble nginx autoindex
and index functionality (combined).
|
|
We allow applications to drop persistent connections, this does not
seem forbidden by Rack and gives the app author some control over
the lifetime of a connection.
|
|
These applications are what I'll be using to run on yahns on
my personal server.
Including them here will be helpful for me to find bugs. I've
already found some, the following commits were directly the result
of playing with these extras:
* stream_file: only close FDs we opened ourselves
* worker-less server should not waitpid indiscriminately
* http: do not drop Content-Range from response headers
|
|
This was triggering OOM on my 32-bit machine.
|
|
We parse and use Content-Range, but do not drop it when sending
a response since that would confuse clients.
|
|
When running a static file server, we must account for filesystem
activity outside of our control where files may grow/shrink as
they're being served.
For truncated files, we must abort any persistent connections
downloading a truncated file to avoid confusing clients because
the Content-Length header was already set to the big value.
We also must ensure (we already did so before this commit,
this just adds a test for it) we do not send additional data
when a file grows on us after we've started sending the response.
|
|
We didn't cover this before.
|
|
Increase scans of log files and use shorter sleep intervals
to get faster notification of successful timeout.
|
|
This allows users to specify alternative temporary directories
in case buffers get too large for one filesystem to handle or
to give priority to some clients on certain ports.
|