Documentation fixes

doc/3_4_async.qbk

@@ -29,7 +29,7 @@ in __N3747__, and built-in to __N4588__.
 Since the interfaces provided here are low level, authors of libraries
 may wish to create higher level interfaces using the primitives found
 in this library. Non-trivial applications will want to provide their own
-asychronous initiation functions which perform a series of other,
+asynchronous initiation functions which perform a series of other,
 intermediate asynchronous operations before invoking the final completion
 handler. The set of intermediate actions produced by calling an initiation
 function is known as a ['composed operation]. To ensure full interoperability

doc/4_09_custom_body.qbk

@@ -46,7 +46,7 @@ the body type as it appears in the message. This can be any type. For
 example, a body's value type may specify `std::vector<char>` or even
 `std::list<std::string>`. By also providing suitable definitions of
 corresponding `reader` and `writer` types, messages with that body
-become serializable and parseable respectively.
+become serializable and parsable respectively.
 
 A custom body may even set the value type to something that is not a container
 for body octets, such as a

doc/6_1_streams.qbk

@@ -40,7 +40,7 @@ and `ssl::context` arguments are forwarded to the wrapped stream's constructor:
 
 [note
     Code which declares stream objects using Asio SSL types must
-    toinclude the file `<beast/websocket/ssl.hpp>`.
+    to include the file `<beast/websocket/ssl.hpp>`.
 ]
 
 [heading Non-owning References]

doc/6_4_server.qbk

@@ -123,7 +123,7 @@ request as an HTTP WebSocket Upgrade request, additional overloads of
 [link beast.ref.websocket__stream.accept_ex `accept_ex`],
 [link beast.ref.websocket__stream.async_accept `async_accept`], and
 [link beast.ref.websocket__stream.async_accept_ex `async_accept_ex`]
-are provided which receive the additional buffered octects and consume
+are provided which receive the additional buffered octets and consume
 them as part of the handshake.
 
 In this example, the server reads the initial HTTP message into the

doc/8_1_http_message.qbk

@@ -17,7 +17,7 @@ of the information captured during parsing. More formally, given:
 * `m` is an instance of an HTTP message container
 
 * `x` is a series of octets describing a valid HTTP message in
-  the serialized format decribed in __rfc7230__.
+  the serialized format described in __rfc7230__.
 
 * `S(m)` is a serialization function which produces a series of octets
   from a message container.

doc/8_2_http_comparison.qbk

@@ -23,7 +23,7 @@ as follows:
   Can user defined types be specified? What's the level of conformance to
   to Asio or Networking-TS concepts?
 
-* Check treatment of buffers. Does the library manage the buffers or
+* Check treatment of buffers. Does the library manage the buffers
   or can users provide their own buffers?
 
 * How does the library handle corner cases such as trailers,
@@ -107,7 +107,7 @@ holds the header fields. We note some problems with the container declaration:
   is that cpp-netlib implementations will be less efficient than an
   equivalent __N4588__ conforming implementation.
 
-* The library uses specializatons of `string<Tag>` to change the type
+* The library uses specializations of `string<Tag>` to change the type
   of string used everywhere, including the body, field name and value
   pairs, and extraneous metadata such as source and destination. The
   user may only choose a single type: field name, field values, and

doc/8_4_faq.qbk

@@ -74,7 +74,7 @@ about Beast and other HTTP libraries that have gone through formal review.
     should not be a barrier to acceptance.
 
     The Beast HTTP message model is suitable for HTTP/2 and can be re-used.
-    The IETF HTTP Working Group adopted message compatiblity with HTTP/1.x
+    The IETF HTTP Working Group adopted message compatibility with HTTP/1.x
     as an explicit goal. A parser can simply emit full headers after
     decoding the compressed HTTP/2 headers. The stream ID is not logically
     part of the message but rather message metadata and should be
@@ -222,7 +222,7 @@ about Beast and other HTTP libraries that have gone through formal review.
 [[
     "You should send a 100-continue to ask for the rest of the body if required."
 ][
-    The Beast interface supporst this functionality (by allowing this
+    The Beast interface supports this functionality (by allowing this
     special case of "split" message parsing and serialization). Specifically,
     it lets callers read the request up to just before the body,
     and let callers write the request up to just before the body. However,
@@ -238,7 +238,7 @@ about Beast and other HTTP libraries that have gone through formal review.
 ][
     Beast.HTTP and Beast.WebSocket are production ready and currently
     running on public servers receiving traffic and handling millions of
-    dollars worth of financial transactions daily. The servers run [*rippled],
+    dollars' worth of financial transactions daily. The servers run [*rippled],
     open source software ([@https://github.com/ripple/rippled repository])
     implementing the
     [@https://ripple.com/files/ripple_consensus_whitepaper.pdf [*Ripple Consensus Protocol]],

doc/x2_0_core.qbk

@@ -386,7 +386,7 @@ in __N3747__, and built-in to __N4588__.
 Since the interfaces provided here are low level, authors of libraries
 may wish to create higher level interfaces using the primitives found
 in this library. Non-trivial applications will want to provide their own
-asychronous initiation functions which perform a series of other,
+asynchronous initiation functions which perform a series of other,
 intermediate asynchronous operations before invoking the final completion
 handler. The set of intermediate actions produced by calling an initiation
 function is known as a ['composed operation]. To ensure full interoperability

include/beast/http/basic_parser.hpp

@@ -370,7 +370,7 @@ public:
 
         In some cases there may be an insufficient number of octets
         in the input buffer in order to make forward progress. This
-        is indicated by the the code @ref error::need_more. When
+        is indicated by the code @ref error::need_more. When
         this happens, the caller should place additional bytes into
         the buffer sequence and call @ref put again.