puma 5.0.0.beta1-java → 5.0.3-java

data/README.md

@@ -4,11 +4,11 @@
 
 # Puma: A Ruby Web Server Built For Concurrency
 
-[![Actions Build Status](https://github.com/puma/puma/workflows/CI/badge.svg?branch=master)](https://github.com/puma/puma/actions)
-
+[![Actions MRI](https://github.com/puma/puma/workflows/MRI/badge.svg?branch=master)](https://github.com/puma/puma/actions?query=workflow%3AMRI)
+[![Actions non MRI](https://github.com/puma/puma/workflows/non_MRI/badge.svg?branch=master)](https://github.com/puma/puma/actions?query=workflow%3Anon_MRI)
 [![Code Climate](https://codeclimate.com/github/puma/puma.svg)](https://codeclimate.com/github/puma/puma)
 [![SemVer](https://api.dependabot.com/badges/compatibility_score?dependency-name=puma&package-manager=bundler&version-scheme=semver)](https://dependabot.com/compatibility-score.html?dependency-name=puma&package-manager=bundler&version-scheme=semver)
-[![StackOverflow](http://img.shields.io/badge/stackoverflow-Puma-blue.svg)]( http://stackoverflow.com/questions/tagged/puma )
+[![StackOverflow](https://img.shields.io/badge/stackoverflow-Puma-blue.svg)]( https://stackoverflow.com/questions/tagged/puma )
 
 Puma is a **simple, fast, multi-threaded, and highly concurrent HTTP 1.1 server for Ruby/Rack applications**.
 
@@ -27,9 +27,17 @@ $ gem install puma
 $ puma
 ```
 
-Without arguments, puma will look for a rackup (.ru) file in 
+Without arguments, puma will look for a rackup (.ru) file in
 working directory called `config.ru`.
 
+## SSL Connection Support
+
+Puma will install/compile with support for ssl sockets, assuming OpenSSL
+development files are installed on the system.
+
+If the system does not have OpenSSL development files installed, Puma will
+install/compile, but it will not allow ssl connections.
+
 ## Frameworks
 
 ### Rails
@@ -135,7 +143,7 @@ Preloading can’t be used with phased restart, since phased restart kills and r
 If puma encounters an error outside of the context of your application, it will respond with a 500 and a simple
 textual error message (see `lowlevel_error` in [this file](https://github.com/puma/puma/blob/master/lib/puma/server.rb)).
 You can specify custom behavior for this scenario. For example, you can report the error to your third-party
-error-tracking service (in this example, [rollbar](http://rollbar.com)):
+error-tracking service (in this example, [rollbar](https://rollbar.com)):
 
 ```ruby
 lowlevel_error_handler do |e|
@@ -266,18 +274,17 @@ end
 
 Puma has support for Capistrano with an [external gem](https://github.com/seuros/capistrano-puma).
 
-It is common to use process monitors with Puma. Modern process monitors like systemd or upstart
+It is common to use process monitors with Puma. Modern process monitors like systemd or rc.d
 provide continuous monitoring and restarts for increased
 reliability in production environments:
 
-* [docs/jungle](https://github.com/puma/puma/tree/master/docs/jungle) for rc.d and upstart
+* [docs/jungle](https://github.com/puma/puma/tree/master/docs/jungle) for rc.d
 * [docs/systemd](https://github.com/puma/puma/blob/master/docs/systemd.md)
 
 ## Community Extensions
 
 ### Plugins
 
-* [puma-heroku](https://github.com/puma/puma-heroku) — default Puma configuration for running on Heroku
 * [puma-metrics](https://github.com/harmjanblok/puma-metrics) — export Puma metrics to Prometheus
 * [puma-plugin-statsd](https://github.com/yob/puma-plugin-statsd) — send Puma metrics to statsd
 * [puma-plugin-systemd](https://github.com/sj26/puma-plugin-systemd) — deeper integration with systemd for notify, status and watchdog

data/bin/puma-wild

@@ -5,24 +5,18 @@
 
 require 'rubygems'
 
-gems = ARGV.shift
+cli_arg = ARGV.shift
 
 inc = ""
 
-if gems == "-I"
+if cli_arg == "-I"
   inc = ARGV.shift
   $LOAD_PATH.concat inc.split(":")
-  gems = ARGV.shift
-end
-
-gems.split(",").each do |s|
-  name, ver = s.split(":",2)
-  gem name, ver
 end
 
 module Puma; end
 
-Puma.const_set("WILD_ARGS", ["-I", inc, gems])
+Puma.const_set("WILD_ARGS", ["-I", inc])
 
 require 'puma/cli'
 

data/docs/architecture.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-![http://bit.ly/2iJuFky](images/puma-general-arch.png)
+![https://bit.ly/2iJuFky](images/puma-general-arch.png)
 
 Puma is a threaded web server, processing requests across a TCP or UNIX socket.
 
@@ -12,7 +12,7 @@ Clustered mode is shown/discussed here. Single mode is analogous to having a sin
 
 ## Connection pipeline
 
-![http://bit.ly/2zwzhEK](images/puma-connection-flow.png)
+![https://bit.ly/2zwzhEK](images/puma-connection-flow.png)
 
 * Upon startup, Puma listens on a TCP or UNIX socket.
   * The backlog of this socket is configured (with a default of 1024), determining how many established but unaccepted connections can exist concurrently.
@@ -29,7 +29,7 @@ Clustered mode is shown/discussed here. Single mode is analogous to having a sin
 
 ### Disabling `queue_requests`
 
-![http://bit.ly/2zxCJ1Z](images/puma-connection-flow-no-reactor.png)
+![https://bit.ly/2zxCJ1Z](images/puma-connection-flow-no-reactor.png)
 
 The `queue_requests` option is `true` by default, enabling the separate thread used to buffer requests as described above.
 

data/docs/deployment.md

@@ -1,4 +1,4 @@
-# Deployment engineering for puma
+# Deployment engineering for Puma
 
 Puma is software that is expected to be run in a deployed environment eventually.
 You can certainly use it as your dev server only, but most people look to use
@@ -7,12 +7,11 @@ it in their production deployments as well.
 To that end, this is meant to serve as a foundation of wisdom how to do that
 in a way that increases happiness and decreases downtime.
 
-## Specifying puma
+## Specifying Puma
 
 Most people want to do this by putting `gem "puma"` into their Gemfile, so we'll
 go ahead and assume that. Go add it now... we'll wait.
 
-
 Welcome back!
 
 ## Single vs Cluster mode
@@ -20,7 +19,10 @@ Welcome back!
 Puma was originally conceived as a thread-only webserver, but grew the ability to
 also use processes in version 2.
 
-Here are some rules of thumb:
+To run `puma` in single mode (e.g. for a development environment) you will need to
+set the number of workers to 0, anything above will run in cluster mode.
+
+Here are some rules of thumb for cluster mode:
 
 ### MRI
 
@@ -66,7 +68,8 @@ thread to become available.
 
 * Have your upstream proxy set a header with the time it received the request:
     * nginx: `proxy_set_header X-Request-Start "${msec}";`
-    * haproxy: `http-request set-header X-Request-Start "%t";`
+    * haproxy >= 1.9: `http-request set-header X-Request-Start t=%[date()]%[date_us()]`
+    * haproxy < 1.9: `http-request set-header X-Request-Start t=%[date()]`
 * In your Rack middleware, determine the amount of time elapsed since `X-Request-Start`.
 * To improve accuracy, you will want to subtract time spent waiting for slow clients:
     * `env['puma.request_body_wait']` contains the number of milliseconds Puma spent
@@ -78,7 +81,7 @@ thread to become available.
 
 Daemonization was removed in Puma 5.0. For alternatives, continue reading.
 
-I prefer to not daemonize my servers and use something like `runit` or `upstart` to
+I prefer to not daemonize my servers and use something like `runit` or `systemd` to
 monitor them as child processes. This gives them fast response to crashes and
 makes it easy to figure out what is going on. Additionally, unlike `unicorn`,
 puma does not require daemonization to do zero-downtime restarts.
@@ -88,7 +91,7 @@ task and thus want it to live on past the `cap deploy`. To these people I say:
 You need to be using a process monitor. Nothing is making sure puma stays up in
 this scenario! You're just waiting for something weird to happen, puma to die,
 and to get paged at 3am. Do yourself a favor, at least the process monitoring
-your OS comes with, be it `sysvinit`, `upstart`, or `systemd`. Or branch out
+your OS comes with, be it `sysvinit` or `systemd`. Or branch out
 and use `runit` or hell, even `monit`.
 
 ## Restarting

data/docs/jungle/README.md

@@ -1,9 +1,5 @@
 # Puma as a service
 
-## Upstart
-
-See `/docs/jungle/upstart` for Ubuntu's upstart scripts.
-
 ## Systemd
 
 See [/docs/systemd](https://github.com/puma/puma/blob/master/docs/systemd.md).

data/docs/jungle/rc.d/puma

@@ -23,7 +23,7 @@ puma_start()
 		rb_ver=$(/usr/local/bin/jq -r ".servers[$i].ruby_version" /usr/local/etc/puma.conf)
 		case $rb_env in
 			"rbenv")
-				su - $user -c "cd $dir && rbenv shell $rb_ver && bundle exec puma -C $dir/config/puma.rb -d"
+				cd $dir && rbenv shell $rb_ver && /usr/sbin/daemon -u $user bundle exec puma -C $dir/config/puma.rb
 				;;
 			*)
 				;;
@@ -48,7 +48,7 @@ puma_restart()
 		rb_ver=$(/usr/local/bin/jq -r ".servers[$i].ruby_version" /usr/local/etc/puma.conf)
 		case $rb_env in
 			"rbenv")
-				su - $user -c "cd $dir && pkill ruby && rbenv shell $ruby_version && bundle exec puma -C $dir/config/puma.rb -d"
+				cd $dir && rbenv shell $rb_ver && /usr/sbin/daemon -u $user bundle exec puma -C $dir/config/puma.rb
 				;;
 			*)
 				;;

data/docs/nginx.md

@@ -31,7 +31,7 @@ server {
 
   location / {
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
-    proxy_set_header Host $http_host;
+    proxy_set_header Host $host;
 
     # If the file exists as a static file serve it directly without
     # running all the other rewrite tests on it

data/docs/restart.md

@@ -1,41 +1,64 @@
-# Restarts
+Puma provides three distinct kinds of restart operations, each for different use cases. Hot restarts and phased restarts are described here. The third kind of restart operation is called "refork" and is described in the documentation for [`fork_worker`](fork_worker.md).
 
-To perform a restart, there are 3 builtin mechanisms:
+## Hot restart
 
-  * Send the `puma` process the `SIGUSR2` signal (normal restart)
-  * Send the `puma` process the `SIGUSR1` signal (restart in phases (a "rolling restart"), cluster mode only)
-  * Use the status server and issue `/restart`
+To perform a "hot" restart, Puma performs an `exec` operation to start the process up again, so no memory is shared between the old process and the new process. As a result, it is safe to issue a restart any place where you would manually stop Puma and start it again. In particular, it is safe to upgrade Puma itself using a hot restart.
 
-No code is shared between the current and restarted process, so it should be safe to issue a restart any place where you would manually stop Puma and start it again.
+If the new process is unable to load, it will simply exit. You should therefore run Puma under a process monitor when using it in production.
 
-If the new process is unable to load, it will simply exit. You should therefore run Puma under a process monitor (see below) when using it in production.
+### How-to
 
-### Normal vs Hot vs Phased Restart
+Any of the following will cause a Puma server to perform a hot restart: 
 
-A hot restart means that no requests will be lost while deploying your new code, since the server socket is kept open between restarts.
+* Send the `puma` process the `SIGUSR2` signal
+* Issue a `GET` request to the Puma status/control server with the path `/restart`
+* Issue `pumactl restart` (this uses the control server method if available, otherwise sends the `SIGUSR2` signal to the process)
 
-But beware, hot restart does not mean that the incoming requests won’t hang for multiple seconds while your new code has not fully deployed. If you need a zero downtime and zero hanging requests deploy, you must use phased restart.
+### Supported configurations
 
-When you run pumactl phased-restart, Puma kills workers one-by-one, meaning that at least another worker is still available to serve requests, which lead to zero hanging requests (yay!).
+* Works in cluster mode and in single mode
+* Supported on all platforms
 
-But again beware, upgrading an application sometimes involves upgrading the database schema. With phased restart, there may be a moment during the deployment where processes belonging to the previous version and processes belonging to the new version both exist at the same time. Any database schema upgrades you perform must therefore be backwards-compatible with the old application version.
+### Client experience
 
-If you perform a lot of database migrations, you probably should not use phased restart and use a normal/hot restart instead (`pumactl restart`). That way, no code is shared while deploying (in that case, `preload_app!` might help for quicker deployment, see ["Clustered Mode" in the README](../README.md#clustered-mode)).
+* All platforms: for clients with an in-flight request, those clients will be served responses before the connection is closed gracefully. Puma gracefully disconnects any idle HTTP persistent connections before restarting.
+* On MRI or TruffleRuby on Linux and BSD: Clients who connect just before the server restarts may experience increased latency while the server stops and starts again, but their connections will not be closed prematurely.
+* On Windows and on JRuby: Clients who connect just before a restart may experience "connection reset" errors.
 
-**Note**: Hot and phased restarts are only available on MRI, not on JRuby. They are also unavailable on Windows servers.
+### Additional notes
 
-### Release Directory
+* Only one version of the application is running at a time.
+* `on_restart` is invoked just before the server shuts down. This can be used to clean up resources (like long-lived database connections) gracefully. Since Ruby 2.0, it is not typically necessary to explicitly close file descriptors on restart. This is because any file descriptor opened by Ruby will have the `FD_CLOEXEC` flag set, meaning that file descriptors are closed on `exec`. `on_restart` is useful, though, if your application needs to perform any more graceful protocol-specific shutdown procedures before closing connections.
 
-If your symlink releases into a common working directory (i.e., `/current` from Capistrano), Puma won't pick up your new changes when running phased restarts without additional configuration. You should set your working directory within Puma's config to specify the directory it should use. This is a change from earlier versions of Puma (< 2.15) that would infer the directory for you.
+## Phased restart
 
-```ruby
-# config/puma.rb
+Phased restarts replace all running workers in a Puma cluster. This is a useful way to gracefully upgrade the application that Puma is serving. A phased restart works by first killing an old worker, then starting a new worker, waiting until the new worker has successfully started before proceeding to the next worker. This process continues until all workers have been replaced. The master process is not restarted.
 
-directory '/var/www/current'
-```
+### How-to
 
-### Cleanup Code
+Any of the following will cause a Puma server to perform a phased restart: 
 
-Puma isn't able to understand all the resources that your app may use, so it provides a hook in the configuration file you pass to `-C` called `on_restart`. The block passed to `on_restart` will be called, unsurprisingly, just before Puma restarts itself.
+* Send the `puma` process the `SIGUSR1` signal
+* Issue a `GET` request to the Puma status/control server with the path `/phased-restart`
+* Issue `pumactl phased-restart` (this uses the control server method if available, otherwise sends the `SIGUSR1` signal to the process)
 
-You should place code to close global log files, redis connections, etc. in this block so that their file descriptors don't leak into the restarted process. Failure to do so will result in slowly running out of descriptors and eventually obscure crashes as the server is restarted many times.
+### Supported configurations
+
+* Works in cluster mode only
+* To support upgrading the application that Puma is serving, ensure `prune_bundler` is enabled and that `preload_app` is disabled (it is disabled by default).
+* Supported on all platforms where cluster mode is supported
+
+### Client experience
+
+* In-flight requests are always served responses before the connection is closed gracefully
+* Idle persistent connections are gracefully disconnected
+* New connections are not lost, and clients will not experience any increase in latency (as long as the number of configured workers is greater than one)
+
+### Additional notes
+
+* When a phased restart begins, the Puma master process changes its current working directory to the directory specified by the `directory` option. If `directory` is set to symlink, this is automatically re-evaluated, so this mechanism can be used to upgrade the application.
+* On a single server, it's possible that two versions of the application are running concurrently during a phased restart.
+* `on_restart` is not invoked
+* Phased restarts can be slow for Puma clusters with many workers. Hot restarts often complete more quickly, but at the cost of increased latency during the restart.
+* Phased restarts cannot be used to upgrade any gems loaded by the Puma master process, including `puma` itself, anything in `extra_runtime_dependencies`, or dependencies thereof. Upgrading other gems is safe.
+* If you remove the gems from old releases as part of your deployment strategy, there are additional considerations. Do not put any gems into `extra_runtime_dependencies` that have native extensions or have dependencies that have native extensions (one common example is `puma_worker_killer` and its dependency on `ffi`). Workers will fail on boot during a phased restart. The underlying issue is recorded in [an issue on the rubygems project](https://github.com/rubygems/rubygems/issues/4004). Hot restarts are your only option here if you need these dependencies.

data/docs/signals.md

@@ -1,8 +1,8 @@
-The [unix signal](http://en.wikipedia.org/wiki/Unix_signal) is a method of sending messages between [processes](http://en.wikipedia.org/wiki/Process_(computing)). When a signal is sent, the operating system interrupts the target process's normal flow of execution. There are standard signals that are used to stop a process but there are also custom signals that can be used for other purposes. This document is an attempt to list all supported signals that Puma will respond to. In general, signals need only be sent to the master process of a cluster.
+The [unix signal](https://en.wikipedia.org/wiki/Unix_signal) is a method of sending messages between [processes](https://en.wikipedia.org/wiki/Process_(computing)). When a signal is sent, the operating system interrupts the target process's normal flow of execution. There are standard signals that are used to stop a process but there are also custom signals that can be used for other purposes. This document is an attempt to list all supported signals that Puma will respond to. In general, signals need only be sent to the master process of a cluster.
 
 ## Sending Signals
 
-If you are new to signals it can be useful to see how they can be used. When a process is created in a *nix like operating system it will have a [PID - or process identifier](http://en.wikipedia.org/wiki/Process_identifier) that can be used to send signals to the process. For demonstration we will create an infinitely running process by tailing a file:
+If you are new to signals it can be useful to see how they can be used. When a process is created in a *nix like operating system it will have a [PID - or process identifier](https://en.wikipedia.org/wiki/Process_identifier) that can be used to send signals to the process. For demonstration we will create an infinitely running process by tailing a file:
 
 ```sh
 $ echo "foo" >> my.log
@@ -17,13 +17,13 @@ $ ps aux | grep tail
 schneems        87152   0.0  0.0  2432772    492 s032  S+   12:46PM   0:00.00 tail -f my.log
 ```
 
-You can send a signal in Ruby using the [Process module](http://www.ruby-doc.org/core-2.1.1/Process.html#kill-method):
+You can send a signal in Ruby using the [Process module](https://www.ruby-doc.org/core-2.1.1/Process.html#kill-method):
 
 ```
 $ irb
 > puts pid
 => 87152
-Process.detach(pid) # http://ruby-doc.org/core-2.1.1/Process.html#method-c-detach
+Process.detach(pid) # https://ruby-doc.org/core-2.1.1/Process.html#method-c-detach
 Process.kill("TERM", pid)
 ```
 
@@ -38,10 +38,10 @@ Puma cluster responds to these signals:
 - `TERM` send `TERM` to worker. Worker will attempt to finish then exit.
 - `USR2` restart workers. This also reloads puma configuration file, if there is one.
 - `USR1` restart workers in phases, a rolling restart. This will not reload configuration file.
-- `HUP`  reopen log files defined in stdout_redirect configuration parameter. If there is no stdout_redirect option provided it will behave like `INT`
-- `INT` equivalent of sending Ctrl-C to cluster. Will attempt to finish then exit.
+- `HUP ` reopen log files defined in stdout_redirect configuration parameter. If there is no stdout_redirect option provided it will behave like `INT`
+- `INT ` equivalent of sending Ctrl-C to cluster. Will attempt to finish then exit.
 - `CHLD`
-- `URG` refork workers in phases from worker 0, if `fork_workers` option is enabled.
+- `URG ` refork workers in phases from worker 0, if `fork_workers` option is enabled.
 
 ## Callbacks order in case of different signals
 

data/docs/systemd.md

@@ -76,7 +76,7 @@ pass the `--keep-file-descriptors` flag. `bundle exec` can be avoided by using a
 `puma` executable generated by `bundle binstubs puma`. This is tracked in
 [#1499].
 
-**Note:** Socket activation doesn't currently work on jruby. This is
+**Note:** Socket activation doesn't currently work on JRuby. This is
 tracked in [#1367].
 
 To use socket activation, configure one or more `ListenStream` sockets

data/ext/puma_http11/ext_help.h

@@ -2,7 +2,7 @@
 #define ext_help_h
 
 #define RAISE_NOT_NULL(T) if(T == NULL) rb_raise(rb_eArgError, "%s", "NULL found for " # T " when shouldn't be.");
-#define DATA_GET(from,type,name) Data_Get_Struct(from,type,name); RAISE_NOT_NULL(name);
+#define DATA_GET(from,type,data_type,name) TypedData_Get_Struct(from,type,data_type,name); RAISE_NOT_NULL(name);
 #define REQUIRE_TYPE(V, T) if(TYPE(V) != T) rb_raise(rb_eTypeError, "%s", "Wrong argument type for " # V " required " # T);
 #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
 

data/ext/puma_http11/http11_parser.c

@@ -14,12 +14,14 @@
 
 /*
  * capitalizes all lower-case ASCII characters,
- * converts dashes to underscores.
+ * converts dashes to underscores, and underscores to commas.
  */
 static void snake_upcase_char(char *c)
 {
     if (*c >= 'a' && *c <= 'z')
       *c &= ~0x20;
+    else if (*c == '_')
+      *c = ',';
     else if (*c == '-')
       *c = '_';
 }

data/ext/puma_http11/http11_parser.rl

@@ -12,12 +12,14 @@
 
 /*
  * capitalizes all lower-case ASCII characters,
- * converts dashes to underscores.
+ * converts dashes to underscores, and underscores to commas.
  */
 static void snake_upcase_char(char *c)
 {
     if (*c >= 'a' && *c <= 'z')
       *c &= ~0x20;
+    else if (*c == '_')
+      *c = ',';
     else if (*c == '-')
       *c = '_';
 }

data/ext/puma_http11/mini_ssl.c

@@ -2,12 +2,7 @@
 
 #include <ruby.h>
 #include <ruby/version.h>
-
-#if RUBY_API_VERSION_MAJOR == 1
-#include <rubyio.h>
-#else
 #include <ruby/io.h>
-#endif
 
 #ifdef HAVE_OPENSSL_BIO_H
 
@@ -33,7 +28,8 @@ typedef struct {
   int bytes;
 } ms_cert_buf;
 
-void engine_free(ms_conn* conn) {
+void engine_free(void *ptr) {
+  ms_conn *conn = ptr;
   ms_cert_buf* cert_buf = (ms_cert_buf*)SSL_get_app_data(conn->ssl);
   if(cert_buf) {
     OPENSSL_free(cert_buf->buf);
@@ -45,10 +41,16 @@ void engine_free(ms_conn* conn) {
   free(conn);
 }
 
+const rb_data_type_t engine_data_type = {
+    "MiniSSL/ENGINE",
+    { 0, engine_free, 0 },
+    0, 0, RUBY_TYPED_FREE_IMMEDIATELY,
+};
+
 ms_conn* engine_alloc(VALUE klass, VALUE* obj) {
   ms_conn* conn;
 
-  *obj = Data_Make_Struct(klass, ms_conn, 0, engine_free, conn);
+  *obj = TypedData_Make_Struct(klass, ms_conn, &engine_data_type, conn);
 
   conn->read = BIO_new(BIO_s_mem());
   BIO_set_nbio(conn->read, 1);
@@ -198,7 +200,7 @@ VALUE engine_init_server(VALUE self, VALUE mini_ssl_ctx) {
   else {
     min = TLS1_VERSION;
   }
-  
+
   SSL_CTX_set_min_proto_version(ctx, min);
 
   SSL_CTX_set_options(ctx, ssl_options);
@@ -281,7 +283,7 @@ VALUE engine_inject(VALUE self, VALUE str) {
   ms_conn* conn;
   long used;
 
-  Data_Get_Struct(self, ms_conn, conn);
+  TypedData_Get_Struct(self, ms_conn, &engine_data_type, conn);
 
   StringValue(str);
 
@@ -301,6 +303,7 @@ void raise_error(SSL* ssl, int result) {
   char msg[512];
   const char* err_str;
   int err = errno;
+  int mask = 4095;
   int ssl_err = SSL_get_error(ssl, result);
   int verify_err = (int) SSL_get_verify_result(ssl);
 
@@ -317,8 +320,8 @@ void raise_error(SSL* ssl, int result) {
     } else {
       err = (int) ERR_get_error();
       ERR_error_string_n(err, buf, sizeof(buf));
-      snprintf(msg, sizeof(msg), "OpenSSL error: %s - %d", buf, err);
-
+      int errexp = err & mask;
+      snprintf(msg, sizeof(msg), "OpenSSL error: %s - %d", buf, errexp);
     }
   } else {
     snprintf(msg, sizeof(msg), "Unknown OpenSSL error: %d", ssl_err);
@@ -333,7 +336,7 @@ VALUE engine_read(VALUE self) {
   char buf[512];
   int bytes, error;
 
-  Data_Get_Struct(self, ms_conn, conn);
+  TypedData_Get_Struct(self, ms_conn, &engine_data_type, conn);
 
   ERR_clear_error();
 
@@ -360,7 +363,7 @@ VALUE engine_write(VALUE self, VALUE str) {
   ms_conn* conn;
   int bytes;
 
-  Data_Get_Struct(self, ms_conn, conn);
+  TypedData_Get_Struct(self, ms_conn, &engine_data_type, conn);
 
   StringValue(str);
 
@@ -384,7 +387,7 @@ VALUE engine_extract(VALUE self) {
   size_t pending;
   char buf[512];
 
-  Data_Get_Struct(self, ms_conn, conn);
+  TypedData_Get_Struct(self, ms_conn, &engine_data_type, conn);
 
   pending = BIO_pending(conn->write);
   if(pending > 0) {
@@ -403,7 +406,7 @@ VALUE engine_shutdown(VALUE self) {
   ms_conn* conn;
   int ok;
 
-  Data_Get_Struct(self, ms_conn, conn);
+  TypedData_Get_Struct(self, ms_conn, &engine_data_type, conn);
 
   ERR_clear_error();
 
@@ -418,7 +421,7 @@ VALUE engine_shutdown(VALUE self) {
 VALUE engine_init(VALUE self) {
   ms_conn* conn;
 
-  Data_Get_Struct(self, ms_conn, conn);
+  TypedData_Get_Struct(self, ms_conn, &engine_data_type, conn);
 
   return SSL_in_init(conn->ssl) ? Qtrue : Qfalse;
 }
@@ -431,7 +434,7 @@ VALUE engine_peercert(VALUE self) {
   ms_cert_buf* cert_buf = NULL;
   VALUE rb_cert_buf;
 
-  Data_Get_Struct(self, ms_conn, conn);
+  TypedData_Get_Struct(self, ms_conn, &engine_data_type, conn);
 
   cert = SSL_get_peer_certificate(conn->ssl);
   if(!cert) {
@@ -462,6 +465,16 @@ VALUE engine_peercert(VALUE self) {
   return rb_cert_buf;
 }
 
+/* @see Puma::MiniSSL::Socket#ssl_version_state
+ * @version 5.0.0
+ */
+static VALUE
+engine_ssl_vers_st(VALUE self) {
+  ms_conn* conn;
+  TypedData_Get_Struct(self, ms_conn, &engine_data_type, conn);
+  return rb_ary_new3(2, rb_str_new2(SSL_get_version(conn->ssl)), rb_str_new2(SSL_state_string(conn->ssl)));
+}
+
 VALUE noop(VALUE self) {
   return Qnil;
 }
@@ -493,27 +506,27 @@ void Init_mini_ssl(VALUE puma) {
 #else
   rb_define_const(mod, "OPENSSL_LIBRARY_VERSION", rb_str_new2(SSLeay_version(SSLEAY_VERSION)));
 #endif
- 
-#if defined(OPENSSL_NO_SSL3) || defined(OPENSSL_NO_SSL3_METHOD) 
-  /* True if SSL3 is not available */ 
-  rb_define_const(mod, "OPENSSL_NO_SSL3", Qtrue); 
-#else 
-  rb_define_const(mod, "OPENSSL_NO_SSL3", Qfalse); 
-#endif 
-
-#if defined(OPENSSL_NO_TLS1) || defined(OPENSSL_NO_TLS1_METHOD) 
-  /* True if TLS1 is not available */ 
-  rb_define_const(mod, "OPENSSL_NO_TLS1", Qtrue); 
-#else 
-  rb_define_const(mod, "OPENSSL_NO_TLS1", Qfalse); 
-#endif 
-
-#if defined(OPENSSL_NO_TLS1_1) || defined(OPENSSL_NO_TLS1_1_METHOD) 
-  /* True if TLS1_1 is not available */ 
-  rb_define_const(mod, "OPENSSL_NO_TLS1_1", Qtrue); 
-#else 
-  rb_define_const(mod, "OPENSSL_NO_TLS1_1", Qfalse); 
-#endif 
+
+#if defined(OPENSSL_NO_SSL3) || defined(OPENSSL_NO_SSL3_METHOD)
+  /* True if SSL3 is not available */
+  rb_define_const(mod, "OPENSSL_NO_SSL3", Qtrue);
+#else
+  rb_define_const(mod, "OPENSSL_NO_SSL3", Qfalse);
+#endif
+
+#if defined(OPENSSL_NO_TLS1) || defined(OPENSSL_NO_TLS1_METHOD)
+  /* True if TLS1 is not available */
+  rb_define_const(mod, "OPENSSL_NO_TLS1", Qtrue);
+#else
+  rb_define_const(mod, "OPENSSL_NO_TLS1", Qfalse);
+#endif
+
+#if defined(OPENSSL_NO_TLS1_1) || defined(OPENSSL_NO_TLS1_1_METHOD)
+  /* True if TLS1_1 is not available */
+  rb_define_const(mod, "OPENSSL_NO_TLS1_1", Qtrue);
+#else
+  rb_define_const(mod, "OPENSSL_NO_TLS1_1", Qfalse);
+#endif
 
   rb_define_singleton_method(mod, "check", noop, 0);
 
@@ -533,6 +546,8 @@ void Init_mini_ssl(VALUE puma) {
   rb_define_method(eng, "init?", engine_init, 0);
 
   rb_define_method(eng, "peercert", engine_peercert, 0);
+
+  rb_define_method(eng, "ssl_vers_st", engine_ssl_vers_st, 0);
 }
 
 #else