diff --git a/README.md b/README.md index 07afea3632..b89e68082d 100644 --- a/README.md +++ b/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: -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.