Date | Commit message (Collapse) |
|
Ugh, it sucks that other servers are so tolerant of violations
of the Rack spec. Rainbows! had the same problem:
https://bogomips.org/rainbows-public/20140704195032.GA13152@dcvr.yhbt.net/
|
|
The Ruby default parameters on top of OpenSSL seem designed
for client usage. For server usage, requiring client-side
certificate verification is uncommon for HTTPS sites.
So follow what WEBrick does for HTTPS and use SSL_VERIFY_NONE
in our documentation.
Thanks-to: Shota Fukumori (sora_h) <her@sorah.jp>
on the unicorn list:
<CA+wiQwuE=ya6F4s4k3GCTUppk7mbBOYOVwVXhTsX2SP8mgdmNQ@mail.gmail.com>
|
|
This release ensures OpenSSL::SSL::SSLContext#session_id_context
is always set for OpenSSL users. It won't overwrite existing
settings, but setting it to a random value is necessary to
ensure clients do not get aborted connections when attempting to
use a session cache.
No need to actually upgrade if you're on 1.12.1, you may add the
following to your yahns_config(5) file where
OpenSSL::SSL::SSLContext is configured:
# recommended, not required. This sets safer defaults
# provided by Ruby on top of what OpenSSL gives:
ssl_ctx.set_params
# required, and done by default in v1.12.2:
ssl_ctx.session_id_context ||= OpenSSL::Random.random_bytes(32)
yahns gives you full control of of how OpenSSL::SSL::SSLContext is
configured. To avoid bugs, yahns only ensures
OpenSSL::SSL::SSLContext#session_id_context is set (if not previously
set by the user) and calls OpenSSL::SSL::SSLContext#setup before
spawning threads to avoid race conditions. yahns itself does not and
will not enforce any opinion on the compatibility/performance/security
trade-offs regarding TLS configuration.
Note: keep in mind using an SSL session cache may be less useful
with yahns because HTTP/1.1 persistent connections may live
forever :)
3 bug/doc fixes on top of v1.12.1:
document OpenSSL::SSL::SSLContext#set_params use
ssl: ensure is session_id_context is always set
test/*: fix mktmpdir usage for 1.9.3
|
|
I use whatever Ruby developers deem to be reasonable defaults.
Because compatibility with old systems is still valued, these
may not be the safest possible configuration; but ought to be
better than what OpenSSL upstream provides by default.
|
|
Remove all pandoc references. We shouldn't need to clutter our
documentation with out-of-date references to pandoc, and pod2man is
probably widely-available enough that nobody should need to install
it.
Reduce HTTP redirects when linking to external sites.
It's also excessive to mention libkqueue as using the native
implementation (whether it be kqueue or epoll) is preferred
and easier.
|
|
epoll and kqueue are similar and we use them in a similar way;
so mention kqueue alongside epoll for users who may already be
familiar with kqueue on *BSD but not epoll under Linux.
epoll is a queue, too!
|
|
Correctly link to subsections within the same page, and include
a link to mailing list archives.
Also, use "ssl_ctx" consistently as a local variable as
we internally use "ctx" for other purposes.
|
|
With the advent of Let's Encrypt, we'll see more users
interested in using yahns with OpenSSL support.
So document how a listener may be passed an SSLContext.
|
|
The "threads:" option for the "listen" directive is worthless.
Having a dedicated thread per-process is already more than enough
(and ideal) for a multi-process setup. Multiple acceptor threads
is still wrong for a single-process setup (even if we did not
have a GVL) as it still incurs contention with the worker
pool within the kernel.
So remove the documentation regarding "listen ... threads: ",
for now; at least until somebody can prove it's useful and not
taking up space.
Additionally, "atfork_parent" may be useful for restarting
background threads/connections if somebody wants to run
background jobs in the master process, so stop saying
it's completely useless.
|
|
pod2man(1) and pod2text(1) are already installed on most modern
GNU/Linix systems including Debian and RedHat-based systems;
pandoc(1) and Haskell are not, and we do not wish to waste
precious bandwidth and disk space of potential packagers.
perlpod(1) is also better standardized than any Markdown flavor,
especially when it comes to generating manpages.
Finally, I'm mildly proficient at Perl (it is similar to Ruby)
and can poke around at the source if I encounter breakage.
|
|
Using the 'update-copyright' script from gnulib[1]:
git ls-files | UPDATE_COPYRIGHT_HOLDER='all contributors' \
UPDATE_COPYRIGHT_USE_INTERVALS=2 \
xargs /path/to/gnulib/build-aux/update-copyright
We're also switching to 'GPL-3.0+' as recommended by SPDX
to be consistent with our gemspec and other metadata
(as opposed to the longer but equivalent "GPLv3 or later").
[1] git://git.savannah.gnu.org/gnulib.git
|
|
Users tend to skip reading release notes, ensure the manpage
documents this feature.
|
|
Future updates may use the update-copyright script in gnulib:
git ls-files | UPDATE_COPYRIGHT_HOLDER='all contributors' \
UPDATE_COPYRIGHT_USE_INTERVALS=2 \
xargs /path/to/gnulib/build-aux/update-copyright
|
|
This is probably the least useful tuning knob and may be removed
in the future; so at least warn users about it.
ref: <CAA2_N1t_UJZO9Vu9vx3NxysCx+okip8_pM+NpwhHrExM+f1e+Q@mail.gmail.com>
|
|
I actually forgot we have the part where we yield a client at the
end of every HTTP/1.x request. This hurts cache CPU cache locality,
but I bet there's other things in Ruby which destroy CPU cache
locality much more than this.
Hopefully we don't forget this stuff for HTTP/2, because concurrency
for that is so tricky with muliplexed connections!
|
|
Rubyforge is going away on May 15, so update our docs for it.
|
|
Users may be tempted to disable buffering because it improves
synthetic benchmark performance. Synthetic benchmarks are
just that and not indicative of what evil (or really crippled)
clients can do to a server.
|
|
If worker_processes are not enabled, our SIGCHLD handler may
conflict with one installed by the application. Fortunately it is
uncommon in Ruby web apps to rely on SIGCHLD, but it happens and
that is bad.
|
|
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.
|
|
This should make it easier for Rack users to get started with yahns.
|
|
Users unfamiliar with the design may be confused by the fact
there are two types of thread pools in a yahns process.
|
|
This should allow users to more-easily enable/disable apps
and their dependent atfork_* hooks.
|
|
This allows modifying the command-line (as an array) passed to
Kernel#exec, as well as running anything necessary.
|
|
The default value was incorrect, also expand on common reasons
why it should be tweaked.
|
|
Otherwise, the server may stay running forever if a client chooses
to stay forever (and there is no FD pressure).
|
|
This is probably not needed and just adds contention, but it makes
experimenting easier.
While we're at it, validate minimum values of for sndbuf/rcvbuf
along with this new threads value, too.
|
|
This should be compatible with the "gem-man" command.
|
|
8K is the default for nginx, too. This prevents Ruby/malloc from
getting too fragmented with large buffers and being unable to release
memory back to the OS.
While we're at it, update the documentation to reflect we use this
parameter to control read(2) sizes, too.
|
|
This was documented (incorrectly) and not implemented for either
the master/worker or single process cases. Implement and test
all (with mocks, so not fully-tested).
|
|
This should hopefully make yahns more appealing and easier-to-use.
|