yahns Ruby server user/dev discussion
 help / color / mirror / code / Atom feed
From: Eric Wong <normalperson@yhbt.net>
To: ruby-talk@ruby-lang.org, yahns-public@yhbt.net
Subject: [ANN] yahns 1.12.0 -_- sleepy app server for Ruby
Date: Sun, 14 Feb 2016 22:37:32 +0000	[thread overview]
Message-ID: <20160214-yahns-1.12.0-released@yhbt.net> (raw)

A Free Software, multi-threaded, non-blocking network
application server designed for low _idle_ power consumption.
It is primarily optimized for applications with occasional users
which see little or no traffic.  yahns currently hosts Rack/HTTP
applications, but may eventually support other application
types.  Unlike some existing servers, yahns is extremely
sensitive to fatal bugs in the applications it hosts.

Changes:

    yahns 1.12.0 - TLS fixes and more!

    Most notably, serving static files over HTTPS did not work
    before this release with the "sendfile" gem installed.  The
    yahns_config(5) manpage is also updated with an example for
    using OpenSSL::SSL::SSLContext objects.  Users of
    Rack::Request#scheme and env['rack.url_scheme'] should see
    "https" properly set for HTTPS connections.

    There's also a bunch of internal tweaks like taking advantage of
    the file-level frozen_string_literal: directive in 2.3 and
    explicitly clearing short-lived string buffers

    TLS support is still in its early stages, but I'm experimenting
    with Let's Encrypt (via getssl[1]) and hosting https://YHBT.net/
    on it.

    For now, I suggest using a separate yahns instance (with a
    different master process) to avoid any potential data leaks
    between HTTPS and HTTP instances.  In the future, it may be
    possible to isolate HTTPS from HTTP at the worker process level.
    Supporting GnuTLS (alongside OpenSSL) may be in our future, too.

    To paraphrase the warning in http://www.postfix.org/TLS_README.html
    (which was written before Heartbleed):

        WARNING

          By turning on TLS support in yahns, you not only get the
          ability to encrypt traffic and to authenticate remote
          clients.  You also turn on thousands and thousands of
          lines of OpenSSL library code.  Assuming that OpenSSL is
          written as carefully as Eric's own code, every 1000 lines
          introduce one additional bug into yahns.

    I'm not nearly as careful with yahns as Wietse is with postfix,
    either.

    20 changes since v1.11.0:
          README: updates for kqueue
          add .gitattributes for Ruby method detection
          nodoc internals
          enable frozen_string_literal for Ruby 2.3+
          copyright updates for 2016
          extras/exec_cgi: fix frozen string error on slow responses
          avoid StringIO#binmode for the next few years
          use String#clear for short-lived buffers we create
          gemspec: make rack a development dependency
          build: install-gem forced to "--local" domain
          acceptor: all subclasses of TCPServer use TCP_INFO
          properly emulate sendfile for OpenSSL sockets
          avoid race conditions in OpenSSL::SSL::SSLContext#setup
          set HTTPS and rack.url_scheme in Rack env as appropriate
          proxy_pass: pass X-Forwarded-Proto through
          doc: switch to perlpod (from pandoc-flavored Markdown)
          doc: trim down documentation slightly
          doc: document ssl_ctx for "listen" directive
          doc: various doc and linkification improvements
          http_context: reduce constant lookup + bytecode

    [1] git clone https://github.com/srvrco/getssl.git

Please note the disclaimer:

  yahns is extremely sensitive to fatal bugs in the apps it hosts.  There
  is no (and never will be) any built-in "watchdog"-type feature to kill
  stuck processes/threads.  Each yahns process may be handling thousands
  of clients; unexpectedly killing the process will abort _all_ of those
  connections.  Lives may be lost!

  yahns hackers are not responsible for your application/library bugs.
  Use an application server which is tolerant of buggy applications
  if you cannot be bothered to fix all your fatal bugs.

* git clone git://yhbt.net/yahns
* http://yahns.yhbt.net/README
* http://yahns.yhbt.net/NEWS.atom.xml
* we only accept plain-text email yahns-public@yhbt.net
* and archive all the mail we receive: http://yhbt.net/yahns-public/
* nntp://news.public-inbox.org/inbox.comp.lang.ruby.yahns

             reply	other threads:[~2016-02-14 22:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-14 22:37 Eric Wong [this message]
2016-02-15  6:00 ` [ANN] yahns 1.12.0 -_- sleepy app server for Ruby Eric Wong
2016-02-22  0:43 ` [ANN] yahns 1.12.1 " Eric Wong
2016-03-01  1:58   ` [ANN] yahns 1.12.2 " Eric Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://yhbt.net/yahns/README

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160214-yahns-1.12.0-released@yhbt.net \
    --to=normalperson@yhbt.net \
    --cc=ruby-talk@ruby-lang.org \
    --cc=yahns-public@yhbt.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhbt.net/yahns.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).