Fix some typos

README.md

@@ -84,7 +84,7 @@ service_past_wait: false  # RACK_TIMEOUT_SERVICE_PAST_WAIT
 term_on_timeout:   false  # RACK_TIMEOUT_TERM_ON_TIMEOUT
 ```
 
-These settings can be overriden during middleware initialization or
+These settings can be overridden during middleware initialization or
 environment variables `RACK_TIMEOUT_*` mentioned above. Middleware
 parameters take precedence:
 

doc/settings.md

@@ -58,7 +58,7 @@ If your application timeouts fire frequently then [they can cause your applicati
 - [Ruby Application Restart Behavior](https://devcenter.heroku.com/articles/what-happens-to-ruby-apps-when-they-are-restarted)
 - [License to SIGKILL](https://www.sitepoint.com/license-to-sigkill/)
 
-**Puma SIGTERM behavior** When a Puma worker receives a `SIGTERM` it will begin to shut down, but not exit right away. It stops accepting new requests and waits for any existing requests to finish before fully shutting down. This means that only the request that experiences a timeout will be interupted, all other in-flight requests will be allowed to run until they return or also are timed out.
+**Puma SIGTERM behavior** When a Puma worker receives a `SIGTERM` it will begin to shut down, but not exit right away. It stops accepting new requests and waits for any existing requests to finish before fully shutting down. This means that only the request that experiences a timeout will be interrupted, all other in-flight requests will be allowed to run until they return or also are timed out.
 
 After the worker process exists will Puma's parent process know to boot a replacement worker. While one process is restarting, another can still serve requests (if you have more than 1 worker process per server/dyno). Between when a process exits and when a new process boots, there will be a reduction in throughput. If all processes are restarting, then incoming requests will be blocked while new processes boot.
 

lib/rack/timeout/core.rb

@@ -78,7 +78,7 @@ def initialize(app, service_timeout:nil, wait_timeout:nil, wait_overtime:nil, se
         raise(NotImplementedError, <<-MSG)
 The platform running your application does not support forking (i.e. Windows, JVM, etc).
 
-To avoid this error, either specify RACK_TIMEOUT_TERM_ON_TIMEOUT=0 or 
+To avoid this error, either specify RACK_TIMEOUT_TERM_ON_TIMEOUT=0 or
 leave it as default (which will have the same result).
 
 MSG
@@ -103,7 +103,7 @@ def call(env)
         seconds_waited          = time_started_service - time_started_wait # how long it took between the web server first receiving the request and rack being able to handle it
         seconds_waited          = 0 if seconds_waited < 0                  # make up for potential time drift between the routing server and the application server
         final_wait_timeout      = wait_timeout + effective_overtime        # how long the request will be allowed to have waited
-        seconds_service_left    = final_wait_timeout - seconds_waited      # first calculation of service timeout (relevant if request doesn't get expired, may be overriden later)
+        seconds_service_left    = final_wait_timeout - seconds_waited      # first calculation of service timeout (relevant if request doesn't get expired, may be overridden later)
         info.wait               = seconds_waited                           # updating the info properties; info.timeout will be the wait timeout at this point
         info.timeout            = final_wait_timeout
 

test/test_helper.rb

@@ -27,7 +27,7 @@ def app
     end
   end
 
-  # runs the test with the given environment, but doesnt restore the original
+  # runs the test with the given environment, but doesn't restore the original
   # environment afterwards. This should be sufficient for rack-timeout testing.
   def with_env(hash)
     hash.each_pair do |k, v|