From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-2.7 required=3.0 tests=ALL_TRUSTED,AWL,BAYES_00, RP_MATCHES_RCVD,URIBL_BLOCKED shortcircuit=no autolearn=unavailable version=3.3.2 X-Original-To: yahns-public@yhbt.net Received: from localhost (dcvr.yhbt.net [127.0.0.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPSA id B101320276; Sun, 14 Feb 2016 22:37:32 +0000 (UTC) Date: Sun, 14 Feb 2016 22:37:32 +0000 From: Eric Wong To: ruby-talk@ruby-lang.org, yahns-public@yhbt.net Subject: [ANN] yahns 1.12.0 -_- sleepy app server for Ruby Message-ID: <20160214-yahns-1.12.0-released@yhbt.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline List-Id: 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