Fix all the typos

guides/https.md

@@ -236,7 +236,7 @@ So far this document has focused on configuring Plug to handle TLS within the ap
 
 ### Pros and Cons
 
-Offloading might be done to achieve higher throughput, or to stick to the more widely used OpenSSL implementation of the TLS protocol. The Erlang/OTP implementation depends on OpenSSL for the underlying cryptography, but it implements its own message framing and protocol state machine. While it is not clear that one implementation is inherently more secure than the other, just patching OpenSSL along with everybody else in case of vulnerabilities might give peace of mind, compared to than having to research the implications on the Erlang/OTP implementation.
+Offloading might be done to achieve higher throughput, or to stick to the more widely used OpenSSL implementation of the TLS protocol. The Erlang/OTP implementation depends on OpenSSL for the underlying cryptography, but it implements its own message framing and protocol state machine. While it is not clear that one implementation is inherently more secure than the other, just patching OpenSSL along with everybody else in case of vulnerabilities might give peace of mind, compared to having to research the implications on the Erlang/OTP implementation.
 
 On the other hand, the proxy solution might not support end-to-end HTTP 2, limiting the benefits of the new protocol. It can also introduce operational complexities and new resource constraints, especially for long-lived connections such as WebSockets.
 

lib/plug.ex

@@ -4,7 +4,7 @@ defmodule Plug do
 
   ## Types of plugs
 
-  There are two kind of plugs: function plugs and module plugs.
+  There are two kinds of plugs: function plugs and module plugs.
 
   ### Function plugs
 
@@ -77,7 +77,7 @@ defmodule Plug do
   Run a series of plugs at runtime.
 
   The plugs given here can be either a tuple, representing a module plug
-  and their options, or a simple function that receives a connection and
+  and its options, or a simple function that receives a connection and
   returns a connection.
 
   If any plug halts, the connection won't invoke the remaining plugs. If the

lib/plug/application.ex

@@ -3,7 +3,7 @@ defmodule Plug.Application do
   use Application
 
   def start(_, _) do
-    # While Plug.Crypto provides its own cache, Plug ship its own too,
+    # While Plug.Crypto provides its own cache, Plug ships its own too,
     # both to keep storages separate and for backwards compatibility.
     Plug.Keys = :ets.new(Plug.Keys, [:named_table, :public, read_concurrency: true])
 

lib/plug/basic_auth.ex

@@ -31,7 +31,7 @@ defmodule Plug.BasicAuth do
   Both approaches shown above rely on static configuration. Let's see
   alternatives.
 
-  ## Runtime-time usage
+  ## Runtime usage
 
   As any other Plug, we can use the `basic_auth` at runtime by simply
   wrapping it in a function:

lib/plug/conn.ex

@@ -65,7 +65,7 @@ defmodule Plug.Conn do
 
   More can be stored in a session cookie, but be careful: this makes requests
   and responses heavier, and clients may reject cookies beyond a certain size.
-  Also, session cookie are not shared between a user's different browsers or devices.
+  Also, session cookies are not shared between a user's different browsers or devices.
   If the session is stored elsewhere, such as a database, the browser only has to
   store the session key and therefore more data can be stored in the session.
 
@@ -125,7 +125,7 @@ defmodule Plug.Conn do
 
   ## Custom status codes
 
-  `Plug` allows status codes to be overridden or added and allow new codes not directly
+  `Plug` allows status codes to be overridden or added and allows new codes not directly
   specified by `Plug` or its adapters. The `:plug` application's Mix config can add or
   override a status code.
 
@@ -1218,8 +1218,8 @@ defmodule Plug.Conn do
   > #### Request length {: .warning}
   >
   > The `:length` option tracks the maximum length within a single call.
-  > When doing multiple across to `read_part_headers/2` and `read_part_body/2`,
-  > it is your responsability to track the overall response length.
+  > When doing multiple calls to `read_part_headers/2` and `read_part_body/2`,
+  > it is your responsibility to track the overall response length.
   """
   @spec read_part_headers(t, Keyword.t()) ::
           {:ok, headers, t} | {:error, :too_large, t} | {:done, t}
@@ -1276,8 +1276,8 @@ defmodule Plug.Conn do
   > #### Request length {: .warning}
   >
   > The `:length` option tracks the maximum length within a single call.
-  > When doing multiple across to `read_part_headers/2` and `read_part_body/2`,
-  > it is your responsability to track the overall response length.
+  > When doing multiple calls to `read_part_headers/2` and `read_part_body/2`,
+  > it is your responsibility to track the overall response length.
   """
   @spec read_part_body(t, Keyword.t()) :: {:ok, binary, t} | {:more, binary, t} | {:done, t}
   def read_part_body(%Conn{adapter: {adapter, state}} = conn, opts) do
@@ -1456,7 +1456,7 @@ defmodule Plug.Conn do
   If the upgrade is accepted by the adapter, the returned `Plug.Conn` will have a `state` of
   `:upgraded`. This state is considered equivalently to a 'sent' state, and is subject to the same
   limitation on subsequent mutating operations. Note that there is no guarantee or expectation
-  that the actual upgrade process has succeeded, or event that it is undertaken within this
+  that the actual upgrade process has succeeded, or even that it is undertaken within this
   function; it is entirely possible (likely, even) that the server will only do the actual upgrade
   later in the connection lifecycle.
 

lib/plug/conn/adapter.ex

@@ -173,7 +173,7 @@ defmodule Plug.Conn.Adapter do
   @doc """
   Attempt to upgrade the connection with the client.
 
-  If the adapter does not support the indicated upgrade, then `{:error, :not_supported}` should be
+  If the adapter does not support the indicated upgrade, then `{:error, :not_supported}` should
   be returned.
 
   If the adapter supports the indicated upgrade but is unable to proceed with it (due to

lib/plug/csrf_protection.ex

@@ -122,7 +122,7 @@ defmodule Plug.CSRFProtection do
     message =
       "invalid CSRF (Cross Site Request Forgery) token, please make sure that:\n\n" <>
         "  * The session cookie is being sent and session is loaded\n" <>
-        "  * The request include a valid '_csrf_token' param or 'x-csrf-token' header"
+        "  * The request includes a valid '_csrf_token' param or 'x-csrf-token' header"
 
     defexception message: message, plug_status: 403
   end

lib/plug/parsers/multipart.ex

@@ -31,7 +31,7 @@ defmodule Plug.Parsers.MULTIPART do
   ## Multipart to params
 
   Once all multiparts are collected, they must be converted to params and this
-  can be customize with a MFA. The default implementation of this function
+  can be customized with an MFA. The default implementation of this function
   is equivalent to:
 
       def multipart_to_params(parts, conn) do
@@ -62,7 +62,7 @@ defmodule Plug.Parsers.MULTIPART do
 
   ## Dynamic configuration
 
-  If you need to dynamically configure how `Plug.Parsers.MULTIPART` behave,
+  If you need to dynamically configure how `Plug.Parsers.MULTIPART` behaves,
   for example, based on the connection or another system parameter, one option
   is to create your own parser that wraps it:
 

lib/plug/router.ex

@@ -125,9 +125,9 @@ defmodule Plug.Router do
   Handling request data can be done through the
   [`Plug.Parsers`](https://hexdocs.pm/plug/Plug.Parsers.html#content) plug. It
   provides support for parsing URL-encoded, form-data, and JSON data as well as
-  providing a behaviour that others parsers can adopt.
+  providing a behaviour that other parsers can adopt.
 
-  Here is an example of `Plug.Parsers` can be used in a `Plug.Router` router to
+  Here is an example of how `Plug.Parsers` can be used in a `Plug.Router` router to
   parse the JSON-encoded body of a POST request:
 
       defmodule AppRouter do

lib/plug/session/cookie.ex

@@ -18,7 +18,7 @@ defmodule Plug.Session.COOKIE do
 
   ## Options
 
-    * `:secret_key_base` - the secret key base to built the cookie
+    * `:secret_key_base` - the secret key base to build the cookie
       signing/encryption on top of. If one is given on initialization,
       the cookie store can precompute all relevant values at compilation
       time. Otherwise, the value is taken from `conn.secret_key_base`

lib/plug/ssl.ex

@@ -131,7 +131,7 @@ defmodule Plug.SSL do
   This function accepts all options defined
   [in Erlang/OTP `:ssl` documentation](http://erlang.org/doc/man/ssl.html).
 
-  Besides the options from `:ssl`, this function adds on extra option:
+  Besides the options from `:ssl`, this function adds one extra option:
 
     * `:cipher_suite` - it may be `:strong` or `:compatible`,
       as outlined in the following section
@@ -141,7 +141,7 @@ defmodule Plug.SSL do
     * `secure_renegotiate: true` - to avoid certain types of man-in-the-middle attacks
     * `reuse_sessions: true` - for improved handshake performance of recurring connections
 
-  For a complete guide on HTTPS and best pratices, see [our Plug HTTPS Guide](https.html).
+  For a complete guide on HTTPS and best practices, see [our Plug HTTPS Guide](https.html).
 
   ## Cipher Suites
 

lib/plug/static.ex

@@ -66,7 +66,7 @@ defmodule Plug.Static do
       that use etags. Defaults to `"public"`.
 
     * `:etag_generation` - specify a `{module, function, args}` to be used
-      to generate   an etag. The `path` of the resource will be passed to
+      to generate an etag. The `path` of the resource will be passed to
       the function, as well as the `args`. If this option is not supplied,
       etags will be generated based off of file size and modification time.
       Note it is [recommended for the etag value to be quoted](https://tools.ietf.org/html/rfc7232#section-2.3),

lib/plug/telemetry.ex

@@ -14,7 +14,7 @@ defmodule Plug.Telemetry do
       options given to the plug under `:options`.
 
     * `[:my, :plug, :stop]` - emitted right before the response is sent.
-      The event carries a single measurement, `:duration`,  which is the
+      The event carries a single measurement, `:duration`, which is the
       monotonic time difference between the stop and start events.
       It has the same metadata as the start event, except the connection
       has been updated.

lib/plug/test.ex

@@ -13,7 +13,7 @@ defmodule Plug.Test do
     * import all the functions from this module
     * import all the functions from the `Plug.Conn` module
 
-  By default, Plug tests checks for invalid header keys, e.g. header keys which
+  By default, Plug tests check for invalid header keys, e.g. header keys which
   include uppercase letters, and raises a `Plug.Conn.InvalidHeaderError` when
   it finds one. To disable it, set `:validate_header_keys_during_test` to
   false on the app config.
@@ -143,7 +143,7 @@ defmodule Plug.Test do
   ## Examples
 
       conn = conn(:get, "/foo", "bar=10")
-      upgrades = Plug.Test.send_upgrades(conn)
+      upgrades = Plug.Test.sent_upgrades(conn)
       assert {:websocket, [opt: :value]} in upgrades
 
   """

lib/plug/upload.ex

@@ -225,7 +225,7 @@ defmodule Plug.Upload do
 
   @impl true
   def handle_call({:give_away, pid, tmp, path}, _from, state) do
-    # Since we are writing in behalf of another process, we need to make sure
+    # Since we are writing on behalf of another process, we need to make sure
     # the monitor and writing to the tables happen within the same operation.
     Process.monitor(pid)
     :ets.insert_new(@dir_table, {pid, tmp})

test/plug/adapters/test/conn_test.exs

@@ -128,7 +128,7 @@ defmodule Plug.Adapters.Test.ConnTest do
     assert child_conn.host == "www.elixir-lang.org"
   end
 
-  test "inform adds to the informational responses to the list" do
+  test "inform adds the informational responses to the list" do
     conn =
       conn(:get, "/")
       |> Plug.Conn.inform(:early_hints, [{"link", "</style.css>; rel=preload; as=style"}])
@@ -140,7 +140,7 @@ defmodule Plug.Adapters.Test.ConnTest do
     assert {103, [{"link", "</script.js>; rel=preload; as=script"}]} in informational_requests
   end
 
-  test "upgrade the supported upgrade request to the list" do
+  test "upgrade adds the supported upgrade request to the list" do
     conn =
       conn(:get, "/")
       |> Plug.Conn.upgrade_adapter(:supported, opt: :supported_value)

test/plug/debugger_test.exs

@@ -163,7 +163,7 @@ defmodule Plug.DebuggerTest do
     assert {200, _headers, "oops"} = sent_resp(conn)
   end
 
-  test "call/2 is overridden and unwrapps wrapped errors" do
+  test "call/2 is overridden and unwraps wrapped errors" do
     conn = put_req_header(conn(:get, "/send_and_wrapped"), "accept", "text/html")
 
     capture_log(fn ->
@@ -426,7 +426,7 @@ defmodule Plug.DebuggerTest do
     assert body =~ action_label
   end
 
-  test "does not render actions when the exception don't implement `Plug.Exception`" do
+  test "does not render actions when the exception doesn't implement `Plug.Exception`" do
     conn =
       conn(:get, "/soft_boom")
       |> put_req_header("accept", "text/html")
@@ -506,7 +506,7 @@ defmodule Plug.DebuggerTest do
     assert body =~ ~s|<input type="hidden" name="last_path" value="#{referer}">|
   end
 
-  test "sets last path as / when request is not a GET and tehre is no referer" do
+  test "sets last path as / when request is not a GET and there is no referer" do
     conn =
       conn(:post, "/actionable_exception")
       |> put_req_header("accept", "text/html")

test/plug/html_test.exs

@@ -1,4 +1,4 @@
-defmodule Plug.HTMlTest do
+defmodule Plug.HTMLTest do
   use ExUnit.Case, async: true
   doctest Plug.HTML
 

test/plug/upload_test.exs

@@ -111,7 +111,7 @@ defmodule Plug.UploadTest do
     end
   end
 
-  test "give_away/3 assigns ownership to other pid fro third party pid" do
+  test "give_away/3 assigns ownership to other pid from third party pid" do
     parent = self()
 
     {other_pid, other_ref} =