Various minor fixes + Copy editing

README.md

@@ -344,11 +344,11 @@ end
 ## Return Values
 
 The return value of a route block determines at least the response body
-passed on to the HTTP client, or at least the next middleware in the
+passed on to the HTTP client or at least the next middleware in the
 Rack stack. Most commonly, this is a string, as in the above examples.
 But other values are also accepted.
 
-You can return any object that would either be a valid Rack response, Rack
+You can return an object that would either be a valid Rack response, Rack
 body object or HTTP status code:
 
 * An Array with three elements: `[status (Integer), headers (Hash), response
@@ -372,7 +372,7 @@ get('/') { Stream.new }
 ```
 
 You can also use the `stream` helper method ([described below](#streaming-responses)) to reduce
-boiler plate and embed the streaming logic in the route.
+boilerplate and embed the streaming logic in the route.
 
 ## Custom Route Matchers
 
@@ -1201,7 +1201,7 @@ end
 ```
 
 Currently, the following rendering methods accept a block: `erb`, `haml`,
-`liquid`, `slim `, `wlang`. Also the general `render` method accepts a block.
+`liquid`, `slim `, `wlang`. Also, the general `render` method accepts a block.
 
 ### Inline Templates
 
@@ -1224,7 +1224,7 @@ __END__
 %div.title Hello world.
 ```
 
-NOTE: Inline templates defined in the source file that requires sinatra are
+NOTE: Inline templates defined in the source file that requires Sinatra are
 automatically loaded. Call `enable :inline_templates` explicitly if you
 have inline templates in other source files.
 
@@ -1434,7 +1434,7 @@ For better security and usability it's
 secret and store it in an environment variable on each host running your
 application so that all of your application instances will share the same
 secret. You should periodically rotate this session secret to a new value.
-Here are some examples of how you might create a 64 byte secret and set it:
+Here are some examples of how you might create a 64-byte secret and set it:
 
 **Session Secret Generation**
 
@@ -1446,7 +1446,7 @@ $ ruby -e "require 'securerandom'; puts SecureRandom.hex(64)"
 **Session Secret Generation (Bonus Points)**
 
 Use the [sysrandom gem](https://github.com/cryptosphere/sysrandom#readme) to
-prefer use of system RNG facilities to generate random values instead of
+use the system RNG facilities to generate random values instead of
 userspace `OpenSSL` which MRI Ruby currently defaults to:
 
 ```text
@@ -1472,7 +1472,7 @@ purposes only:
 
 **Session Secret App Config**
 
-Setup your app config to fail-safe to a secure random secret
+Set up your app config to fail-safe to a secure random secret
 if the `SESSION_SECRET` environment variable is not available.
 
 For bonus points use the [sysrandom
@@ -1593,7 +1593,7 @@ matching route. If no matching route is found, a 404 is returned.
 
 ### Triggering Another Route
 
-Sometimes `pass` is not what you want, instead you would like to get the
+Sometimes `pass` is not what you want, instead, you would like to get the
 result of calling another route. Simply use `call` to achieve this:
 
 ```ruby
@@ -1616,13 +1616,13 @@ than a duplicate, use `call!` instead of `call`.
 
 Check out the Rack specification if you want to learn more about `call`.
 
-### Setting Body, Status Code and Headers
+### Setting Body, Status Code, and Headers
 
 It is possible and recommended to set the status code and response body with
-the return value of the route block. However, in some scenarios you might
+the return value of the route block. However, in some scenarios, you might
 want to set the body at an arbitrary point in the execution flow. You can do
 so with the `body` helper method. If you do so, you can use that method from
-there on to access the body:
+thereon to access the body:
 
 ```ruby
 get '/foo' do
@@ -1645,7 +1645,7 @@ get '/foo' do
   headers \
     "Allow"   => "BREW, POST, GET, PROPFIND, WHEN",
     "Refresh" => "Refresh: 20; https://ietf.org/rfc/rfc2324.txt"
-  body "I'm a tea pot!"
+  body "I'm a teapot!"
 end
 ```
 
@@ -1678,7 +1678,7 @@ also be used to increase throughput if some but not all content depends on a
 slow resource.
 
 Note that the streaming behavior, especially the number of concurrent
-requests, highly depends on the web server used to serve the application.
+requests, highly depends on the webserver used to serve the application.
 Some servers might not even support streaming at all. If the server does not
 support streaming, the body will be sent all at once after the block passed
 to `stream` finishes executing. Streaming does not work at all with Shotgun.
@@ -1763,7 +1763,7 @@ class MyApp < Sinatra::Base
 end
 ```
 
-To avoid any logging middleware to be set up, set the `logging` setting to
+To avoid any logging middleware to be set up, set the `logging` option to
 `nil`. However, keep in mind that `logger` will in that case return `nil`. A
 common use case is when you want to set your own logger. Sinatra will use
 whatever it will find in `env['rack.logger']`.
@@ -1797,7 +1797,7 @@ Haml:
 %a{:href => url('/foo')} foo
 ```
 
-It takes reverse proxies and Rack routers into account, if present.
+It takes reverse proxies and Rack routers into account - if present.
 
 This method is also aliased to `to` (see [below](#browser-redirect) for an example).
 
@@ -2147,7 +2147,7 @@ helpers do
 end
 ```
 
-You can also easily wrap this up in an extension and share with others!
+You can also easily wrap this up in an extension and share it with others!
 
 Note that `find_template` does not check if the file really exists but
 rather calls the given block for all possible paths. This is not a
@@ -2236,7 +2236,7 @@ set :protection, :except => [:path_traversal, :session_hijacking]
 By default, Sinatra will only set up session based protection if `:sessions`
 have been enabled. See '[Using Sessions](#using-sessions)'. Sometimes you may want to set up
 sessions "outside" of the Sinatra app, such as in the config.ru or with a
-separate `Rack::Builder` instance. In that case you can still set up session
+separate `Rack::Builder` instance. In that case, you can still set up session
 based protection by passing the `:session` option:
 
 ```ruby
@@ -2717,7 +2717,7 @@ modular application.
 The main disadvantage of using the classic style rather than the modular
 style is that you will only have one Sinatra application per Ruby
 process. If you plan to use more than one, switch to the modular style.
-There is no reason you cannot mix the modular and the classic styles.
+There is no reason you cannot mix the modular and classic styles.
 
 If switching from one style to the other, you should be aware of
 slightly different default settings:
@@ -2846,7 +2846,7 @@ style for running with a `config.ru`.**
 ### Using Sinatra as Middleware
 
 Not only is Sinatra able to use other Rack middleware, any Sinatra
-application can in turn be added in front of any Rack endpoint as
+application can, in turn, be added in front of any Rack endpoint as
 middleware itself. This endpoint could be another Sinatra application,
 or any other Rack-based application (Rails/Hanami/Roda/...):
 
@@ -2937,7 +2937,7 @@ available.
 Every Sinatra application corresponds to a subclass of `Sinatra::Base`.
 If you are using the top-level DSL (`require 'sinatra'`), then this
 class is `Sinatra::Application`, otherwise it is the subclass you
-created explicitly. At class level you have methods like `get` or
+created explicitly. At the class level, you have methods like `get` or
 `before`, but you cannot access the `request` or `session` objects, as
 there is only a single application class for all requests.
 
@@ -2960,7 +2960,7 @@ You have the application scope binding inside:
 * Your application class body
 * Methods defined by extensions
 * The block passed to `helpers`
-* Procs/blocks used as value for `set`
+* Procs/blocks used as a value for `set`
 * The block passed to `Sinatra.new`
 
 You can reach the scope object (the class) like this:
@@ -3011,7 +3011,7 @@ do not share variables/state with the class scope (read: you have a different
 
 You have the delegate scope binding inside:
 
-* The top level binding, if you did `require "sinatra"`
+* The top-level binding, if you did `require "sinatra"`
 * An object extended with the `Sinatra::Delegator` mixin
 
 Have a look at the code for yourself: here's the
@@ -3044,7 +3044,7 @@ _Paraphrasing from
 [this StackOverflow answer](https://stackoverflow.com/a/6282999/5245129)
 by Konstantin_
 
-Sinatra doesn't impose any concurrency model, but leaves that to the
+Sinatra doesn't impose any concurrency model but leaves that to the
 underlying Rack handler (server) like Puma or WEBrick. Sinatra
 itself is thread-safe, so there won't be any problem if the Rack handler
 uses a threaded model of concurrency. This would mean that when starting
@@ -3105,7 +3105,7 @@ The following Ruby versions are officially supported:
   </dd>
 </dl>
 
-Versions of Ruby prior to 2.3 are no longer supported as of Sinatra 2.1.0.
+Versions of Ruby before 2.3 are no longer supported as of Sinatra 2.1.0.
 
 We also keep an eye on upcoming Ruby versions.