puma 8.1.0-java → 8.1.1-java

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: puma
 version: !ruby/object:Gem::Version
-  version: 8.1.0
+  version: 8.1.1
 platform: java
 authors:
 - Evan Phoenix
@@ -42,15 +42,19 @@ files:
 - bin/puma
 - bin/puma-wild
 - bin/pumactl
-- docs/5.0-Upgrade.md
-- docs/6.0-Upgrade.md
-- docs/7.0-Upgrade.md
-- docs/8.0-Upgrade.md
 - docs/architecture.md
+- docs/binding.md
+- docs/cluster_mode.md
 - docs/compile_options.md
-- docs/deployment.md
-- docs/fork_worker.md
-- docs/grpc.md
+- docs/configuration.md
+- docs/control_server.md
+- docs/deployment/README.md
+- docs/deployment/kubernetes.md
+- docs/deployment/nginx.md
+- docs/deployment/rc.d/README.md
+- docs/deployment/rc.d/puma
+- docs/deployment/rc.d/puma.conf
+- docs/deployment/systemd.md
 - docs/images/favicon.svg
 - docs/images/puma-connection-flow-no-reactor.png
 - docs/images/puma-connection-flow.png
@@ -58,35 +62,15 @@ files:
 - docs/images/running-puma.svg
 - docs/images/standard-logo.svg
 - docs/java_options.md
-- docs/jungle/README.md
-- docs/jungle/rc.d/README.md
-- docs/jungle/rc.d/puma
-- docs/jungle/rc.d/puma.conf
-- docs/kubernetes.md
-- docs/nginx.md
 - docs/plugins.md
 - docs/puma_support.md
 - docs/rails_dev_mode.md
 - docs/restart.md
 - docs/signals.md
-- docs/stats.md
-- docs/systemd.md
-- docs/testing_benchmarks_local_files.md
-- docs/testing_test_rackup_ci_files.md
-- ext/puma_http11/PumaHttp11Service.java
-- ext/puma_http11/extconf.rb
-- ext/puma_http11/http11_parser.c
-- ext/puma_http11/http11_parser.h
-- ext/puma_http11/http11_parser.java.rl
-- ext/puma_http11/http11_parser.rl
-- ext/puma_http11/http11_parser_common.rl
-- ext/puma_http11/mini_ssl.c
-- ext/puma_http11/no_ssl/PumaHttp11Service.java
-- ext/puma_http11/org/jruby/puma/EnvKey.java
-- ext/puma_http11/org/jruby/puma/Http11.java
-- ext/puma_http11/org/jruby/puma/Http11Parser.java
-- ext/puma_http11/org/jruby/puma/MiniSSL.java
-- ext/puma_http11/puma_http11.c
+- docs/upgrading/5.0-Upgrade.md
+- docs/upgrading/6.0-Upgrade.md
+- docs/upgrading/7.0-Upgrade.md
+- docs/upgrading/8.0-Upgrade.md
 - lib/puma.rb
 - lib/puma/app/status.rb
 - lib/puma/binder.rb
@@ -132,8 +116,6 @@ files:
 - lib/puma/thread_pool.rb
 - lib/puma/util.rb
 - lib/rack/handler/puma.rb
-- tools/Dockerfile
-- tools/trickletest.rb
 homepage: https://puma.io
 licenses:
 - BSD-3-Clause
@@ -158,7 +140,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
     - !ruby/object:Gem::Version
       version: '0'
 requirements: []
-rubygems_version: 4.0.21
+rubygems_version: 4.0.23
 specification_version: 4
 summary: A Ruby/Rack web server built for parallelism.
 test_files: []

data/docs/fork_worker.md

@@ -1,71 +0,0 @@
-# Fork-Worker Cluster Mode [Experimental]
-
-`fork_worker` (`--fork-worker` from the CLI) is an experimental cluster-mode configuration option. This mode causes Puma to fork additional workers from worker 0, instead of directly from the master process.
-
-```
-10000   \_ puma 8.0.2 (tcp://0.0.0.0:9292) [puma]
-10001       \_ puma: cluster worker 0: 10000 [puma]
-10002           \_ puma: cluster worker 1: 10000 [puma]
-10003           \_ puma: cluster worker 2: 10000 [puma]
-10004           \_ puma: cluster worker 3: 10000 [puma]
-```
-
-The `fork_worker` option allows your application to be initialized only once for copy-on-write memory savings, and it has two additional advantages:
-
-1. **Compatible with phased restart.** With `preload_app!` disabled, the master process doesn't load the application, so this mode works with phased restart (`SIGUSR1` or `pumactl phased-restart`). When worker 0 reloads as part of a phased restart, it initializes a new copy of your application first, then the other workers reload by forking from this new worker already containing the new preloaded application.
-
-   This allows a phased restart to complete as quickly as a hot restart (`SIGUSR2` or `pumactl restart`), while still minimizing downtime by staggering the restart across cluster workers.
-
-2. **'Refork' for additional copy-on-write improvements in running applications.** Fork-worker mode introduces a new `refork` command that re-loads all nonzero workers by re-forking them from worker 0.
-
-   This command can potentially improve memory utilization in large or complex applications that don't fully pre-initialize on startup, because the re-forked workers can share copy-on-write memory with a worker that has been running for a while and serving requests.
-
-   You can trigger a refork by sending the cluster the `SIGURG` signal or running the `pumactl refork` command at any time. A refork will also automatically trigger once, after a certain number of requests have been processed by worker 0 (default 1000). To configure the number of requests before the auto-refork, pass a positive integer argument to `fork_worker` (e.g., `fork_worker 1000`), or `0` to disable.
-
-### Usage Considerations
-
-- `fork_worker` introduces new `before_refork` and `after_refork` configuration hooks. Note the following:
-    - When initially forking the parent process to the worker 0 child, `before_fork` will trigger on the parent process and `before_worker_boot` will trigger on the worker 0 child as normal.
-    - When forking the worker 0 child to grandchild workers, `before_refork` and `after_refork` will trigger on the worker 0 child, and `before_worker_boot` will trigger on each grandchild worker.
-    - For clarity, `before_fork` does not trigger on worker 0, and `after_refork` does not trigger on the grandchild.
-- As a general migration guide:
-    - Copy any logic within your existing `before_fork` hook to the `before_refork` hook.
-    - Consider copying logic from your `before_worker_boot` hook to the `after_refork` hook, if it is needed to reset the state of worker 0 after it forks.
-
-### Limitations
-
-- This mode is still very experimental so there may be bugs or edge-cases, particularly around expected behavior of existing hooks. Please open a [bug report](https://github.com/puma/puma/issues/new?template=bug_report.md) if you encounter any issues.
-
-- In order to fork new workers cleanly, worker 0 shuts down its server and stops serving requests so there are no open file descriptors or other kinds of shared global state between processes, and to maximize copy-on-write efficiency across the newly-forked workers. This may temporarily reduce total capacity of the cluster during a phased restart / refork.
-
-- In a cluster with `n` workers, a normal phased restart stops and restarts workers one by one while the application is loaded in each process, so `n-1` workers are available serving requests during the restart. In a phased restart in fork-worker mode, the application is first loaded in worker 0 while `n-1` workers are available, then worker 0 remains stopped while the rest of the workers are reloaded one by one, leaving only `n-2` workers to be available for a brief period of time. Reloading the rest of the workers should be quick because the application is preloaded at that point, but there may be situations where it can take longer (slow clients, long-running application code, slow worker-fork hooks, etc).
-
-# Mold-Worker Cluster Mode [Experimental]
-
-`mold_worker` (`--mold-worker` from the CLI) is an alternative to `fork_worker`. Instead of forking from a worker that also serves requests, Puma promotes a worker to a "mold", which stops serving requests and only forks new workers. Because the mold never serves traffic, a slow request, timeout or memory limit can't take it down mid-refork.
-
-```
-10000   \_ puma 8.0.2 (tcp://0.0.0.0:9292) [puma]
-10005       \_ puma: mold 2: 10000 [puma]
-10011           \_ puma: cluster worker 0: 10000 [puma]
-10012           \_ puma: cluster worker 1: 10000 [puma]
-10013           \_ puma: cluster worker 2: 10000 [puma]
-```
-
-Workers are forked from the master at boot. Each request threshold (default `1000`) promotes the busiest worker to a new mold, retires the previous one, and reforks every worker from the new mold.
-
-```ruby
-mold_worker 1000, 2000, 4000
-```
-
-### Usage Considerations
-
-- Thresholds are per worker, counted from when that worker booted. Workers forked from a mold start again at zero, so with the config above a worker is promoted after 1000 requests, and a worker from that generation is promoted after another 2000.
-- After the last threshold, molds are only replaced by `SIGURG` or `pumactl refork`, which promote the busiest worker at any time.
-- A phased restart (`SIGUSR1` or `pumactl phased-restart`) retires the mold and forks workers from the master, so new code is loaded, then starts the thresholds again. As with any phased restart, this requires `preload_app!` to be disabled.
-- `mold_worker` cannot be combined with `fork_worker`.
-- On Linux 3.4+, workers are reparented to the master rather than orphaned if their mold exits.
-- `mold_worker` introduces new `after_mold_promotion` and `before_mold_shutdown` configuration hooks.
-    - `after_mold_promotion` runs in the mold after it stops serving requests, before it forks any workers. Use it for what you would do in `before_refork`, such as closing connections or running garbage collection.
-    - `before_mold_shutdown` runs in the mold before it exits.
-    - `before_worker_boot` runs in each forked worker, as usual. Use it for what you would do in `after_refork`.

data/docs/grpc.md

@@ -1,62 +0,0 @@
-# Using gRPC with Puma in Clustered Mode
-
-This guide shows how to set up gRPC with Puma in a clustered environment using Puma's hooks to manage gRPC's lifecycle methods during forking.
-
-## The Problem
-
-In a clustered Puma setup, you might encounter the following error when using gRPC:
-
-```
-grpc cannot be used between calls to GRPC.prefork and GRPC.postfork_child or GRPC.postfork_parent
-```
-
-To work correctly, gRPC needs these methods called at specific points in the process lifecycle:
-- `GRPC.prefork`: Called before forking.
-- `GRPC.postfork_child`: Called in the child process after forking.
-- `GRPC.postfork_parent`: Called in the parent process after forking.
-
-Puma provides hooks such as `before_worker_fork`, `after_worker_fork`, and `before_worker_boot` to execute code during these lifecycle events. Understanding the behavior of these hooks is key to ensuring gRPC operates correctly in a clustered setup.
-
-## The Solution
-
-### Example Configuration
-
-This configuration integrates gRPC's lifecycle methods in a clustered Puma setup and works whether preloading is enabled or not.
-
-```ruby
-# config/puma.rb
-
-is_mac = RUBY_PLATFORM.include?("darwin")
-
-before_worker_fork do |index|
-  GRPC.prefork unless is_mac
-end
-
-after_worker_fork do |index|
-  GRPC.postfork_parent unless is_mac
-end
-
-before_worker_boot do
-  GRPC.postfork_child unless is_mac
-end
-```
-
-### Understanding the Lifecycle and Hooks
-
-Puma's hooks determine when to call gRPC's lifecycle methods. Each hook plays a specific role in managing the lifecycle during forking:
-
-- **`before_worker_fork`**:
-  - This hook runs before forking workers and is where you call `GRPC.prefork`.
-  - In preloading setups (default in Puma v7), it runs in the **master process** before workers are forked, as the application is preloaded in the master process.
-  - Without preloading, it still runs in the **master process** before forking workers, but the application is not preloaded.
-  - `GRPC.prefork` is called here to prepare GRPC for the forking process.
-
-- **`after_worker_fork`**:
-  - This hook always runs in the **master process** after a worker is forked, regardless of whether preloading is enabled.
-  - Call `GRPC.postfork_parent` here to finalize the master process's state after forking.
-
-- **`before_worker_boot`**:
-  - This hook always runs in the **worker process** after it is forked, regardless of whether preloading is enabled.
-  - Call `GRPC.postfork_child` here to finalize the worker's state.
-
-**Note**: On macOS, these methods are skipped because gRPC does not require them due to differences in how forking works.

data/docs/jungle/README.md

@@ -1,9 +0,0 @@
-# Puma as a service
-
-## Systemd
-
-See [/docs/systemd](https://github.com/puma/puma/blob/main/docs/systemd.md).
-
-## rc.d
-
-See `/docs/jungle/rc.d` for FreeBSD's rc.d scripts

data/docs/testing_benchmarks_local_files.md

@@ -1,150 +0,0 @@
-# Testing - benchmark/local files
-
-These files generate data that shows request-per-second (RPS), etc. Typically, files are in 
-pairs, a shell script and a Ruby script. The shell script starts the server, then runs the 
-Ruby file, which starts client request stream(s), then collects and logs metrics.
-
-## response_time_wrk.sh
-
-This uses [wrk] for generating data. One or more wrk runs are performed. Summarizes RPS and 
-wrk latency times. The default for the `-b` argument runs 28 different client request streams, 
-and takes a bit over 5 minutes.  See 'Request Stream Configuration' below for `-b` argument
-description.
-
-<details>
-  <summary>Summary output for<br/><code>benchmarks/local/response_time_wrk.sh -w2 -t5:5 -s tcp6</code>:</summary>
-
-```
-Type   req/sec    50%     75%     90%     99%    100%  Resp Size
-─────────────────────────────────────────────────────────────────    1kB
-array   13710    0.74    2.52    5.23    7.76   37.45      1024
-chunk   13502    0.76    2.55    5.28    7.84   11.23      1042
-string  13794    0.74    2.51    5.20    7.75   14.07      1024
-io       9615    1.16    3.45    7.13   10.57   15.75      1024
-─────────────────────────────────────────────────────────────────   10kB
-array   13458    0.76    2.57    5.31    7.93   13.94     10239
-chunk   13066    0.78    2.64    5.46    8.18   38.48     10320
-string  13500    0.76    2.55    5.29    7.88   11.42     10240
-io       9293    1.18    3.59    7.39   10.94   16.99     10240
-─────────────────────────────────────────────────────────────────  100kB
-array   11315    0.96    3.06    6.33    9.49   17.69    102424
-chunk    9916    1.10    3.48    7.20   10.73   15.14    103075
-string  10948    1.00    3.17    6.57    9.83   17.88    102378
-io       8901    1.21    3.72    7.48   11.27   59.98    102407
-─────────────────────────────────────────────────────────────────  256kB
-array    9217    1.15    3.82    7.88   11.74   17.12    262212
-chunk    7339    1.45    4.76    9.81   14.63   22.70    264007
-string   8574    1.19    3.81    7.73   11.21   15.80    262147
-io       8911    1.19    3.80    7.55   15.25   60.01    262183
-─────────────────────────────────────────────────────────────────  512kB
-array    6951    1.49    5.03   10.28   15.90   25.08    524378
-chunk    5234    2.03    6.56   13.57   20.46   32.15    527862
-string   6438    1.55    5.04   10.12   16.28   72.87    524275
-io       8533    1.15    4.62    8.79   48.15   70.51    524327
-───────────────────────────────────────────────────────────────── 1024kB
-array    4122    1.80   15.59   41.87   67.79  121.00   1048565
-chunk    3158    2.82   15.22   31.00   71.39   99.90   1055654
-string   4710    2.24    6.66   13.65   20.38   70.44   1048575
-io       8355    1.23    3.95    7.94   14.08   68.54   1048498
-───────────────────────────────────────────────────────────────── 2048kB
-array    2454    4.12   14.02   27.70   43.48   88.89   2097415
-chunk    1743    6.26   17.65   36.98   55.78   92.10   2111358
-string   2479    4.38   12.52   25.65   38.44   95.62   2097502
-io       8264    1.25    3.83    7.76   11.73   65.69   2097090
-
-Body    ────────── req/sec ──────────   ─────── req 50% times ───────
- KB     array   chunk  string      io   array   chunk  string      io
-1       13710   13502   13794    9615   0.745   0.757   0.741   1.160
-10      13458   13066   13500    9293   0.760   0.784   0.759   1.180
-100     11315    9916   10948    8901   0.960   1.100   1.000   1.210
-256      9217    7339    8574    8911   1.150   1.450   1.190   1.190
-512      6951    5234    6438    8533   1.490   2.030   1.550   1.150
-1024     4122    3158    4710    8355   1.800   2.820   2.240   1.230
-2048     2454    1743    2479    8264   4.120   6.260   4.380   1.250
-─────────────────────────────────────────────────────────────────────
-wrk -t8 -c16 -d10s
-benchmarks/local/response_time_wrk.sh -w2 -t5:5 -s tcp6 -Y
-Server cluster mode -w2 -t5:5, bind: tcp6
-Puma repo branch 00-response-refactor
-ruby 3.2.0dev (2022-06-14T01:21:55Z master 048f14221c) +YJIT [x86_64-linux]
-
-[2136] - Gracefully shutting down workers...
-[2136] === puma shutdown: 2022-06-13 21:16:13 -0500 ===
-[2136] - Goodbye!
-
- 5:15 Total Time
-```
-</details><br/>
-
-## bench_base.sh, bench_base.rb
-
-These two files set up parameters for the Puma server, which is normally started in a shell 
-script. It then starts a Ruby file (a subclass of BenchBase), passing arguments to it. The 
-Ruby file is normally used to generate a client request stream(s).
-
-### Puma Configuration
-
-The following arguments are used for the Puma server:
-
-* **`-C`** - configuration file
-* **`-d`** - app delay
-* **`-r`** - rackup file, often defaults to test/rackup/ci_select.ru
-* **`-s`** - bind socket type, default is tcp/tcp4, also tcp6, ssl/ssl4, ssl6, unix, or aunix
-  (unix & abstract unix are not available with wrk).
-* **`-t`** - threads, expressed as '5:5', same as Puma --thread
-* **`-w`** - workers, same as Puma --worker
-* **`-Y`** - enable Ruby YJIT
-
-### Request Stream Configuration
-
-The following arguments are used for request streams:
-
-* **`-b`** - response body configuration. Body type options are a array, c chunked, s string,
-  and i for File/IO. None or any combination can be specified, they should start the option.
-  Then, any combination of comma separated integers can be used for the response body size
-  in kB. The string 'ac50,100' would create four runs, 50kb array, 50kB chunked, 100kB array,
-  and 100kB chunked. See 'Testing - test/rackup/ci-*.ru files' for more info.
-* **`-c`** - connections per client request stream thread, defaults to 2 for wrk.
-* **`-D`** - duration of client request stream in seconds.
-* **`-T`** - number of threads in the client request stream. For wrk, this defaults to
-  80% of Puma workers * max_threads.
-
-### Notes - Configuration
-
-The above lists script arguments.
-
-`bench_base.sh` contains most server defaults. Many can be set via ENV variables.
-
-`bench_base.rb` contains the client request stream defaults. The default value for
-`-b` is `acsi1,10,100,256,512,1024,2048`, which is a 4 x 7 matrix, and hence, runs
-28 jobs. Also, the i body type (File/IO) generates files, they are placed in the
-`"#{Dir.tmpdir}/.puma_response_body_io"` directory, which is created.
-
-### Notes - wrk
-
-The shell scripts use `-T` for wrk's thread count, since `-t` is used for Puma
-server threads.  Regarding the `-c` argument, wrk has an interesting behavior.
-The total number of connections is set by `(connections/threads).to_i`. The scripts
-here use `-c` as connections per thread.  Hence, using `-T4 -c2` will yield a total
-of eight wrk connections, two per thread. The equivalent wrk arguments would be `-t4 -c8`.
-
-Puma can only process so many requests, and requests will queue in the backlog
-until Puma can respond to them. With wrk, if the number of total connections is
-too high, one will see the upper latency times increase, pushing into the lower
-latency times as the connections are increased. The default values for wrk's
-threads and connections were chosen to minimize requests' time in the backlog.
-
-An example with four wrk runs using `-b s10`.  Notice that `req/sec` varies by
-less than 1%, but the `75%` times increase by an order of magnitude:
-```
-req/sec    50%     75%     90%     99%    100%  Resp Size   wrk cmd line
-─────────────────────────────────────────────────────────────────────────────
- 13597   0.755   2.550   5.260   7.800  13.310     12040    wrk -t8  -c16 -d10
- 13549   0.793   4.430   8.140  11.220  16.600     12002    wrk -t10 -c20 -d10
- 13570   1.040  25.790  40.010  49.070  58.300     11982    wrk -t8  -c64 -d10
- 13684   1.050  25.820  40.080  49.160  66.190     12033    wrk -t16 -c64 -d10
-```
-Finally, wrk's output may cause rounding errors, so the response body size calculation is
-imprecise.
-
-[wrk]: <https://github.com/ioquatix/wrk>

data/docs/testing_test_rackup_ci_files.md

@@ -1,36 +0,0 @@
-# Testing - test/rackup/ci-*.ru files
-
-## Overview
-
-Puma should efficiently handle a variety of response bodies, varying both by size
-and by the type of object used for the body.
-
-Five rackup files are located in 'test/rackup' that can be used.  All have their
-request body size (in kB) set via `Body-Conf` header or with `ENV['CI_BODY_CONF']`.
-Additionally, the ci_select.ru file can have its body type set via a starting
-character.
-
-* **ci_array.ru** - body is an `Array` of 1kB strings.  `Content-Length` is not set.
-* **ci_chunked.ru** - body is an `Enumerator` of 1kB strings.  `Content-Length` is not set.
-* **ci_io.ru** - body is a File/IO object.  `Content-Length` is set.
-* **ci_string.ru** - body is a single string.  `Content-Length` is set.
-* **ci_select.ru** - can be any of the above.
-
-All responses have 25 headers, total length approx 1kB.  ci_array.ru and ci_chunked.ru
-contain 1kB items.
-
-All can be delayed by a float value (seconds) specified by the `Dly` header
-
-Note that the `Body-Conf` header takes precedence, and `ENV['CI_BODY_CONF']` is
-only read on load.
-
-## ci_select.ru
-
-The ci_select.ru file allows a starting character to specify the body type in the
-`Body-Conf` header or with `ENV['CI_BODY_CONF']`.
-* **a** - array of strings
-* **c** - chunked (enum)
-* **s** - single string
-* **i** - File/IO
-
-A value of `a100` would return a body as an array of 100 1kB strings.

data/ext/puma_http11/PumaHttp11Service.java

@@ -1,17 +0,0 @@
-package puma;
-
-import java.io.IOException;
-
-import org.jruby.Ruby;
-import org.jruby.runtime.load.BasicLibraryService;
-
-import org.jruby.puma.Http11;
-import org.jruby.puma.MiniSSL;
-
-public class PumaHttp11Service implements BasicLibraryService {
-    public boolean basicLoad(final Ruby runtime) throws IOException {
-        Http11.createHttp11(runtime);
-        MiniSSL.createMiniSSL(runtime);
-        return true;
-    }
-}

data/ext/puma_http11/extconf.rb

@@ -1,67 +0,0 @@
-require 'mkmf'
-
-dir_config("puma_http11")
-
-if $mingw
-  append_cflags  '-fstack-protector-strong -D_FORTIFY_SOURCE=2'
-  append_ldflags '-fstack-protector-strong -l:libssp.a'
-  have_library 'ssp'
-end
-
-have_func "prctl(PR_SET_CHILD_SUBREAPER, 1)", "sys/prctl.h"
-
-unless ENV["PUMA_DISABLE_SSL"]
-  # don't use pkg_config('openssl') if '--with-openssl-dir' is used
-  has_openssl_dir = dir_config('openssl').any? ||
-    RbConfig::CONFIG['configure_args']&.include?('openssl')
-
-  found_pkg_config = !has_openssl_dir && pkg_config('openssl')
-
-  found_ssl = if !$mingw && found_pkg_config
-    puts '──── Using OpenSSL pkgconfig (openssl.pc) ────'
-    true
-  elsif have_library('libcrypto', 'BIO_read') && have_library('libssl', 'SSL_CTX_new')
-    true
-  elsif %w'crypto libeay32'.find {|crypto| have_library(crypto, 'BIO_read')} &&
-      %w'ssl ssleay32'.find {|ssl| have_library(ssl, 'SSL_CTX_new')}
-    true
-  else
-    puts '** Puma will be compiled without SSL support'
-    false
-  end
-
-  if found_ssl
-    have_header "openssl/bio.h"
-
-    ssl_h = "openssl/ssl.h".freeze
-
-    puts "\n──── Below are yes for 1.0.2 & later ────"
-    have_func "DTLS_method"                            , ssl_h
-    have_func "SSL_CTX_set_session_cache_mode(NULL, 0)", ssl_h
-
-    puts "\n──── Below are yes for 1.1.0 & later ────"
-    have_func "TLS_server_method"                      , ssl_h
-    have_func "SSL_CTX_set_min_proto_version(NULL, 0)" , ssl_h
-
-    puts "\n──── Below is yes for 1.1.0 and later, but isn't documented until 3.0.0 ────"
-    # https://github.com/openssl/openssl/blob/OpenSSL_1_1_0/include/openssl/ssl.h#L1159
-    have_func "SSL_CTX_set_dh_auto(NULL, 0)"           , ssl_h
-
-    puts "\n──── Below is yes for 1.1.1 & later ────"
-    have_func "SSL_CTX_set_ciphersuites(NULL, \"\")"   , ssl_h
-
-    puts "\n──── Below is yes for 3.0.0 & later ────"
-    have_func "SSL_get1_peer_certificate"              , ssl_h
-
-    puts ''
-  end
-end
-
-if ENV["PUMA_MAKE_WARNINGS_INTO_ERRORS"]
-  # Make all warnings into errors
-  # Except `implicit-fallthrough` since most failures comes from ragel state machine generated code
-  append_cflags(config_string('WERRORFLAG') || '-Werror')
-  append_cflags '-Wno-implicit-fallthrough'
-end
-
-create_makefile("puma/puma_http11")