fix typos

docs/cro-tool.md

@@ -83,7 +83,7 @@ subdirectories):
 
 It's also possible to list multiple services:
 
-    cro run flashbard-backend users frontend
+    cro run flashcard-backend users frontend
 
 The output of the services will be displayed, prefixed with the `service-name`.
 Sending SIGINT (hitting Ctrl+C) will kill all of the services.

docs/http-auth-and-sessions.md

@@ -26,7 +26,7 @@ For example:
   can be verified.
 * With a web-based login (login form on a page), typically there will be a
   session object with fields indicating if there is currently a logged in
-  user. The login process would update the sesion object with that information
+  user. The login process would update the session object with that information
   at the time of login, and clear it at the time of logout.
 * For a system without any kind of login, but that simply wishes to hold some
   information about a particular session, then the object would just represent
@@ -248,14 +248,14 @@ The `Cro::HTTP::Auth::WebToken::Bearer` is a role that does
 take the token from `Auth` header of the request object. `set-auth` method
 may be overridden by the user to set a custom object that does
 `Cro::HTTP::Auth` role to `auth` attribute. It is installed as
-middlewere, either at route block or server level.
+middleware, either at route block or server level.
 
 The `Cro::HTTP::Auth::WebToken::FromCookie[Str $cookie-name]` is a
 role that does `Cro::HTTP::Auth::WebToken`. Its `get-token` method is
 overridden to take the token from the request's cookie with given name
 `$cookie-name`. `set-auth` method may be overridden by the user to set
 a custom object that does `Cro::HTTP::Auth` role to `auth`
-attribute. It is installed as middlewere, either at route block or
+attribute. It is installed as middleware, either at route block or
 server level. Additionally, this role checks `exp` claim of parsed
 token. In case it is invalid, the cookie will be removed from the
 request.

docs/releases.md

@@ -132,7 +132,7 @@ The following changes were made to the `Cro::HTTP::Test` distribution:
 
 * Add semantic test subs `is-ok`, `is-no-content`, `is-bad-request`,
   `is-unauthorized`, `is-forbidden`, `is-not-found`, `is-method-not-allowed`,
-  `is-conflict` and `is-unprocessible-entity`
+  `is-conflict` and `is-unprocessable-entity`
 
 The following changes were made to the `Cro` distribution:
 
@@ -447,7 +447,7 @@ authentication and authorization is handled as part of route matching.
 
 The previous behavior (applying middleware only to a route that has been
 matched) is preserved and renamed to `before-matched` and `after-matched`.
-Therefore, any code can be adapated by replacing calls to `before` to
+Therefore, any code can be adapted by replacing calls to `before` to
 use `before-matched`, and replacing calls to `after` to `after-matched`.
 
 The new `before` and `after`-applied middleware semantics result in a
@@ -491,7 +491,7 @@ The following changes were made to the `Cro::HTTP` distribution:
   various ways that it might end up working slowly due to eating too
   many real threads.
 * When a route fails to match with 400 or 401, and another route fails
-  to match with a 405, perfer the 400 or 401 error.
+  to match with a 405, prefer the 400 or 401 error.
 
 The following changes were made to the `Cro::WebSocket` distribution:
 

t/tools-runner.t

@@ -55,7 +55,7 @@ with-test-dir -> $test-dir {
     is $started.service-id, 'service1', 'Correct service ID was started';
     isa-ok $started.cro-file, Cro::Tools::CroFile, 'Have the Cro file object';
     is $started.endpoint-ports.elems, 1, 'Endpoint was assigned a port';
-    ok $started.endpoint-ports<http>:exists, 'HTTP endpoing exists in ports';
+    ok $started.endpoint-ports<http>:exists, 'HTTP endpoint exists in ports';
     my $port = $started.endpoint-ports<http>;
     isa-ok $port, Int, 'Port number available as an Int';