This is an automated email from the ASF dual-hosted git repository.
zwoop pushed a commit to branch 9.1.x
in repository https://gitbox.apache.org/repos/asf/trafficserver.git
The following commit(s) were added to refs/heads/9.1.x by this push:
new 2f6dfdc Fixed spelling mistakes in the docs (#7896)
2f6dfdc is described below
commit 2f6dfdcfbeb8428233d94e5daca5c92dc88176f3
Author: Bryan Call <[email protected]>
AuthorDate: Fri May 28 13:58:25 2021 -0700
Fixed spelling mistakes in the docs (#7896)
(cherry picked from commit 35994e4b81f3d2e7b314753532a64ae5127bcadf)
---
doc/admin-guide/files/records.config.en.rst | 2 +-
doc/admin-guide/files/remap.config.en.rst | 4 ++--
doc/admin-guide/plugins/background_fetch.en.rst | 2 +-
doc/admin-guide/plugins/cachekey.en.rst | 2 +-
doc/admin-guide/plugins/geoip_acl.en.rst | 2 +-
doc/admin-guide/plugins/header_rewrite.en.rst | 2 +-
doc/appendices/command-line/traffic_top.en.rst | 4 ++--
doc/appendices/glossary.en.rst | 2 +-
doc/developer-guide/api/functions/TSClientProtocolStack.en.rst | 2 +-
doc/developer-guide/api/functions/TSHttpTxnReenable.en.rst | 4 ++--
doc/developer-guide/api/functions/TSLifecycleHookAdd.en.rst | 2 +-
doc/developer-guide/api/functions/TSTypes.en.rst | 2 +-
doc/developer-guide/api/functions/TSVConnReenable.en.rst | 6 +++---
doc/developer-guide/cache-architecture/architecture.en.rst | 2 +-
doc/developer-guide/core-architecture/heap.en.rst | 2 +-
doc/developer-guide/documentation/building.en.rst | 2 +-
doc/developer-guide/documentation/ts-markup.en.rst | 2 +-
doc/developer-guide/internal-libraries/buffer-writer.en.rst | 2 +-
.../example-plugins/denylist/setting-up-a-transaction-hook.en.rst | 8 ++++----
.../hooks-and-transactions/http-alternate-selection.en.rst | 2 +-
.../plugins/hooks-and-transactions/http-sessions.en.rst | 2 +-
.../plugins/hooks-and-transactions/ssl-hooks.en.rst | 6 +++---
.../plugins/hooks-and-transactions/trafficserver-timers.en.rst | 2 +-
doc/developer-guide/plugins/http-transformations/index.en.rst | 2 +-
.../http-transformations/sample-null-transformation-plugin.en.rst | 6 +++---
doc/developer-guide/plugins/mutexes.en.rst | 2 +-
doc/developer-guide/release-process/index.en.rst | 2 +-
doc/developer-guide/threads-and-events.en.rst | 2 +-
28 files changed, 40 insertions(+), 40 deletions(-)
diff --git a/doc/admin-guide/files/records.config.en.rst
b/doc/admin-guide/files/records.config.en.rst
index 021b721..2cd2744 100644
--- a/doc/admin-guide/files/records.config.en.rst
+++ b/doc/admin-guide/files/records.config.en.rst
@@ -959,7 +959,7 @@ mptcp
of the origin server matches.
``host`` Re-use server sessions, checking that the fully qualified
domain name matches. In addition, if the session uses TLS, it
also
- checks that the current transaction's host header value
matchs the session's SNI.
+ checks that the current transaction's host header value
matches the session's SNI.
``both`` Equivalent to ``host,ip``.
``hostonly`` Check that the fully qualified domain name matches.
``sni`` Check that the SNI of the session matches the SNI that would
be used to
diff --git a/doc/admin-guide/files/remap.config.en.rst
b/doc/admin-guide/files/remap.config.en.rst
index c1075d3..6df6863 100644
--- a/doc/admin-guide/files/remap.config.en.rst
+++ b/doc/admin-guide/files/remap.config.en.rst
@@ -363,7 +363,7 @@ be verified for validity. If the "~" symbol was specified
before referer
regular expression, it means that the request with a matching referer header
will be redirected to redirectURL. It can be used to create a so-called
negative referer list. If "*" was used as a referer regular expression -
-all referers are allowed. Various combinations of "*" and "~" in a referer
+all referrers are allowed. Various combinations of "*" and "~" in a referer
list can be used to create different filtering rules.
map_with_referer Examples
@@ -379,7 +379,7 @@ Explanation: Referer header must be in the request, only
".*\.bar\.com" and "www
map_with_referer http://y.foo.bar.com/x/yy/ http://foo.bar.com/x/yy/
http://games.bar.com/new_games * ~.*\.evil\.com
-Explanation: Referer header must be in the request but all referers are
allowed except ".*\.evil\.com".
+Explanation: Referer header must be in the request but all referrers are
allowed except ".*\.evil\.com".
::
diff --git a/doc/admin-guide/plugins/background_fetch.en.rst
b/doc/admin-guide/plugins/background_fetch.en.rst
index 8f28a7e..9f578ef 100644
--- a/doc/admin-guide/plugins/background_fetch.en.rst
+++ b/doc/admin-guide/plugins/background_fetch.en.rst
@@ -78,7 +78,7 @@ The contents of the config-file could be as below::
The ``include`` configuration directive is only used when there is a
corresponding ``exclude`` to exempt.
For example, a single line directive, ``include Host example.com`` would
not make the plugin
- *only* act on example.com. To acheive classic allow (only) lists, one would
need to have a broad
+ *only* act on example.com. To achieve classic allow (only) lists, one would
need to have a broad
exclude line, such as::
exclude Host *
diff --git a/doc/admin-guide/plugins/cachekey.en.rst
b/doc/admin-guide/plugins/cachekey.en.rst
index 406256f..a586bc7 100644
--- a/doc/admin-guide/plugins/cachekey.en.rst
+++ b/doc/admin-guide/plugins/cachekey.en.rst
@@ -179,7 +179,7 @@ Cache key structure and related plugin parameters
^^^^^^^^^^^^^^^
* If no query related plugin parameters are used, the query string is included
in the `cache key`.
-* ``--exclude-params`` (default: empty list) - comma-separated list of query
params to be excluded in the `cache key`. If the list is empty then no
exlusions are applied (no query parameters will be excluded from the `cache
key`). The exclude list overrides the include list.
+* ``--exclude-params`` (default: empty list) - comma-separated list of query
params to be excluded in the `cache key`. If the list is empty then no
exclusions are applied (no query parameters will be excluded from the `cache
key`). The exclude list overrides the include list.
* ``--include-params`` (default: empty list) - comma-separated list of query
params to be allow-listed in the `cache key`. If the list is empty then no
allow-list is applied (all query parameters will be included in the `cache
key`).
* ``--include-match-params`` (default: empty list) - regular expression
matching query parameter names which will be allowed in the `cache key`.
* ``--exclude-match-params`` (default: empty list) - regular expression
matching query parameter names which will be excluded in the `cache key`.
diff --git a/doc/admin-guide/plugins/geoip_acl.en.rst
b/doc/admin-guide/plugins/geoip_acl.en.rst
index 9444163..95d1e8e 100644
--- a/doc/admin-guide/plugins/geoip_acl.en.rst
+++ b/doc/admin-guide/plugins/geoip_acl.en.rst
@@ -69,7 +69,7 @@ expressions, and unique rules for match. E.g.::
.*\.ogg deny US
Note that the default in the case of no matches on the regular
-expressions is to "allow" the request. This can be overriden, see next
+expressions is to "allow" the request. This can be overridden, see next
use case.
3. You can also combine 1) and 2), and provide defaults in the
diff --git a/doc/admin-guide/plugins/header_rewrite.en.rst
b/doc/admin-guide/plugins/header_rewrite.en.rst
index e2ff1cd..709653c 100644
--- a/doc/admin-guide/plugins/header_rewrite.en.rst
+++ b/doc/admin-guide/plugins/header_rewrite.en.rst
@@ -429,7 +429,7 @@ RANDOM
cond %{RANDOM:<n>} <operand>
-Generates a random integer from ``0`` up to (but not including) ``<n>``.
Mathmatically, ``[0,n)`` or ``0 <= r < n``.
+Generates a random integer from ``0`` up to (but not including) ``<n>``.
Mathematically, ``[0,n)`` or ``0 <= r < n``.
STATUS
~~~~~~
diff --git a/doc/appendices/command-line/traffic_top.en.rst
b/doc/appendices/command-line/traffic_top.en.rst
index 6998d58..59d8156 100644
--- a/doc/appendices/command-line/traffic_top.en.rst
+++ b/doc/appendices/command-line/traffic_top.en.rst
@@ -152,8 +152,8 @@ PURGE request).
Statistic: :ts:stat:`proxy.process.http.cache_deletes`.
-Read Activ
-~~~~~~~~~~
+Read Active
+~~~~~~~~~~~
Current number of active cache reads.
diff --git a/doc/appendices/glossary.en.rst b/doc/appendices/glossary.en.rst
index 85dc499..913bde2 100644
--- a/doc/appendices/glossary.en.rst
+++ b/doc/appendices/glossary.en.rst
@@ -68,7 +68,7 @@ Glossary
cache volume on a specific cache span is a :term:`cache stripe`.
cache stripe
- A homogenous, persistent store for the cache in a single
+ A homogeneous, persistent store for the cache in a single
:term:`cache span`. A stripe always resides entirely on a single physical
device and is treated as an undifferentiated span of bytes. This is the
smallest independent unit of storage.
diff --git a/doc/developer-guide/api/functions/TSClientProtocolStack.en.rst
b/doc/developer-guide/api/functions/TSClientProtocolStack.en.rst
index 6a8ea43..f9a1698 100644
--- a/doc/developer-guide/api/functions/TSClientProtocolStack.en.rst
+++ b/doc/developer-guide/api/functions/TSClientProtocolStack.en.rst
@@ -76,7 +76,7 @@ the actual number of elements in the protocol stack will be
returned. If this is
be sufficient to hold all of the elements and the function called again with
updated :arg:`count`
and :arg:`result`. In practice the maximum number of elements is almost
certain to be less
than 10 which therefore should suffice. These functions return
:const:`TS_SUCCESS` on success and
-:const:`TS_ERROR` on failure which should only occurr if :arg:`txnp` or
:arg:`ssnp` are invalid.
+:const:`TS_ERROR` on failure which should only occur if :arg:`txnp` or
:arg:`ssnp` are invalid.
The :func:`TSHttpTxnClientProtocolStackContains`,
:func:`TSHttpSsnClientProtocolStackContains`, and
:func:`TSHttpTxnServerProtocolStackContains`
functions are provided for the convenience when only the presence of a
protocol is of interest, not
diff --git a/doc/developer-guide/api/functions/TSHttpTxnReenable.en.rst
b/doc/developer-guide/api/functions/TSHttpTxnReenable.en.rst
index 808226f..807facd 100644
--- a/doc/developer-guide/api/functions/TSHttpTxnReenable.en.rst
+++ b/doc/developer-guide/api/functions/TSHttpTxnReenable.en.rst
@@ -41,6 +41,6 @@ The plugin tells the transaction :arg:`txnp` to either
continue
.. important::
- You must always reenable the HTTP transaction after the processing of
- each transaction event. However, never reenable twice. Reenabling
+ You must always re-enable the HTTP transaction after the processing of
+ each transaction event. However, never re-enable twice. Reenabling
twice is a serious error.
diff --git a/doc/developer-guide/api/functions/TSLifecycleHookAdd.en.rst
b/doc/developer-guide/api/functions/TSLifecycleHookAdd.en.rst
index e3913c1..49e4b33 100644
--- a/doc/developer-guide/api/functions/TSLifecycleHookAdd.en.rst
+++ b/doc/developer-guide/api/functions/TSLifecycleHookAdd.en.rst
@@ -40,7 +40,7 @@ specified by :arg:`id`. Lifecycle hooks are based on the
Traffic Server
process, not on any specific transaction or session. These will typically be
called only once during the execution of the Traffic Server process and
therefore should be added in :func:`TSPluginInit` (which could itself be
-considered a lifecyle hook). Unlike other hooks, lifecycle hooks may not have a
+considered a lifecycle hook). Unlike other hooks, lifecycle hooks may not have
a
well defined ordering and use of them should not assume that one of the hooks
is always called before another unless specifically mentioned.
diff --git a/doc/developer-guide/api/functions/TSTypes.en.rst
b/doc/developer-guide/api/functions/TSTypes.en.rst
index eb35f77..67257ed 100644
--- a/doc/developer-guide/api/functions/TSTypes.en.rst
+++ b/doc/developer-guide/api/functions/TSTypes.en.rst
@@ -311,5 +311,5 @@ more widely. Those are described on this page.
.. member:: int32_t stream_dependency
The stream dependency. Per spec, see RFC 7540 section 6.2, this is 31
- bits. We use a signed 32 bit stucture to store either a valid dependency
+ bits. We use a signed 32 bit structure to store either a valid dependency
or -1 if the stream has no dependency.
diff --git a/doc/developer-guide/api/functions/TSVConnReenable.en.rst
b/doc/developer-guide/api/functions/TSVConnReenable.en.rst
index e77bb03..3f74736 100644
--- a/doc/developer-guide/api/functions/TSVConnReenable.en.rst
+++ b/doc/developer-guide/api/functions/TSVConnReenable.en.rst
@@ -33,17 +33,17 @@ Synopsis
Description
===========
-Reenable the SSL connection :arg:`svc`. If a plugin hook is called, ATS
+Re-enable the SSL connection :arg:`svc`. If a plugin hook is called, ATS
processing on that connection will not resume until this is invoked for that
connection.
If the server is running OpenSSL 1.0.2, the plugin writer can pause SSL
handshake
processing at the certificate callback by not reenabling the connection.
Running an OpenSSL versions older than 1.0.2, the handshake processing in
-``SSL_accept`` will not be stopped even if the SNI callback does not reenable
+``SSL_accept`` will not be stopped even if the SNI callback does not re-enable
the connection.
-Additional processing could reenable the virtual connection causing the
+Additional processing could re-enable the virtual connection causing the
``SSL_accept`` to be called again to complete the handshake exchange. In the
case of a blind tunnel conversion, the SSL handshake will never be completed by
Traffic Server.
diff --git a/doc/developer-guide/cache-architecture/architecture.en.rst
b/doc/developer-guide/cache-architecture/architecture.en.rst
index 2bc3463..202320d 100644
--- a/doc/developer-guide/cache-architecture/architecture.en.rst
+++ b/doc/developer-guide/cache-architecture/architecture.en.rst
@@ -1074,7 +1074,7 @@ Fragments can also be evacuated through *hit evacuation*.
This is configured by
:ts:cv:`proxy.config.cache.hit_evacuate_size_limit`. When a fragment is read it
is checked to see if it is close and in front of the write cursor, close being
less than the specified percent of the size of the stripe. If set at the
default
-value of 10, then if the fragment is withing 10% of the size of the stripe, it
+value of 10, then if the fragment is within 10% of the size of the stripe, it
is marked for evacuation. This is cleared if the write cursor passes through
the
fragment while it remains open (as all open objects are evacuated). If, when
the
object is closed, the fragment is still marked then it is placed in the
diff --git a/doc/developer-guide/core-architecture/heap.en.rst
b/doc/developer-guide/core-architecture/heap.en.rst
index 2f0140a..fd552b1 100644
--- a/doc/developer-guide/core-architecture/heap.en.rst
+++ b/doc/developer-guide/core-architecture/heap.en.rst
@@ -200,7 +200,7 @@ created with twice the space of the last :class:`HdrHeap`
in the list and added
try.
Once space is found for the object, the base members of
:class:`HdrHeapObjImpl` are initialized with
-the objec type and size, with the :arg:`m_obj_flags` set to 0.
+the object type and size, with the :arg:`m_obj_flags` set to 0.
Serialization
-------------
diff --git a/doc/developer-guide/documentation/building.en.rst
b/doc/developer-guide/documentation/building.en.rst
index 51df0e6..ed508ae 100644
--- a/doc/developer-guide/documentation/building.en.rst
+++ b/doc/developer-guide/documentation/building.en.rst
@@ -57,7 +57,7 @@ PIP installs
Support for using `plantuml
<http://plantuml.com/PlantUML_Language_Reference_Guide.pdf>`__ inline.
sphinx-intl
- Internation support, which is needed if a non-English version is built.
Currently a Japanese
+ International support, which is needed if a non-English version is
built. Currently a Japanese
(``JA``) version is available.
These should be also installed using `pipenv
diff --git a/doc/developer-guide/documentation/ts-markup.en.rst
b/doc/developer-guide/documentation/ts-markup.en.rst
index b697351..d0188ec 100644
--- a/doc/developer-guide/documentation/ts-markup.en.rst
+++ b/doc/developer-guide/documentation/ts-markup.en.rst
@@ -132,7 +132,7 @@ Definition
Collection
The key name of the collection in the returned JSON data from the
:ref:`admin-plugins-stats-over-http` plugin. For most statistics, this is
the
- literal sting :literal:`global`. *Required*
+ literal string :literal:`global`. *Required*
Statistic Name
The exact and full name of the statistic. *Required*
diff --git a/doc/developer-guide/internal-libraries/buffer-writer.en.rst
b/doc/developer-guide/internal-libraries/buffer-writer.en.rst
index bae7c06..fa2337d 100644
--- a/doc/developer-guide/internal-libraries/buffer-writer.en.rst
+++ b/doc/developer-guide/internal-libraries/buffer-writer.en.rst
@@ -437,7 +437,7 @@ reasonable without the programmer needing to be explicit.
= ===============
For several specializations the hexadecimal format is taken to indicate
printing the value as if
- it were a hexidecimal value, in effect providing a hex dump of the value.
This is the case for
+ it were a hexadecimal value, in effect providing a hex dump of the value.
This is the case for
:code:`std::string_view` and therefore a hex dump of an object can be done
by creating a
:code:`std::string_view` covering the data and then printing it with
:code:`{:x}`.
diff --git
a/doc/developer-guide/plugins/example-plugins/denylist/setting-up-a-transaction-hook.en.rst
b/doc/developer-guide/plugins/example-plugins/denylist/setting-up-a-transaction-hook.en.rst
index 10ad851..539fafe 100644
---
a/doc/developer-guide/plugins/example-plugins/denylist/setting-up-a-transaction-hook.en.rst
+++
b/doc/developer-guide/plugins/example-plugins/denylist/setting-up-a-transaction-hook.en.rst
@@ -62,11 +62,11 @@ following things happen:
order to add a transaction hook, you need a handle to the transaction
being processed.
-#. The transaction is reenabled using ``TSHttpTxnReenable`` with
+#. The transaction is re-enabled using ``TSHttpTxnReenable`` with
``TS_EVENT_HTTP_ERROR`` as its event argument. Reenabling with an
error event tells the HTTP state machine to stop the transaction and
jump to the "send response header" state. Notice that if the
- requested site is not listed, then the transaction is reenabled
+ requested site is not listed, then the transaction is re-enabled
with the ``TS_EVENT_HTTP_CONTINUE`` event.
#. The string and ``TSMLoc`` data stored in the marshal buffer ``bufp`` is
@@ -75,10 +75,10 @@ following things happen:
handles before re-enabling the transaction.
In general, whenever the plugin is doing something to a transaction, it
-must reenable the transaction when it is finished. In other words: every
+must re-enable the transaction when it is finished. In other words: every
time your handler function handles a transaction event, it must call
``TSHttpTxnReenable`` when it is finished. Similarly, after your plugin
handles session events (``TS_EVENT_HTTP_SSN_START`` and
-``TS_EVENT_HTTP_SSN_CLOSE``), it must reenable the session with
+``TS_EVENT_HTTP_SSN_CLOSE``), it must re-enable the session with
``TSHttpSsnReenable``. Reenabling the transaction twice in the same
plugin routine is a bad error.
diff --git
a/doc/developer-guide/plugins/hooks-and-transactions/http-alternate-selection.en.rst
b/doc/developer-guide/plugins/hooks-and-transactions/http-alternate-selection.en.rst
index d7a6cce..28f61c3 100644
---
a/doc/developer-guide/plugins/hooks-and-transactions/http-alternate-selection.en.rst
+++
b/doc/developer-guide/plugins/hooks-and-transactions/http-alternate-selection.en.rst
@@ -57,7 +57,7 @@ by a call to ``TSHttpAltInfoQualitySet``.
.. note::
- HTTP SM does not have to be reenabled using ``TSHttpTxnReenable`` or any
+ HTTP SM does not have to be re-enabled using ``TSHttpTxnReenable`` or any
other APIs; just return from the function.
The sample code below shows how to call the alternate APIs.
diff --git
a/doc/developer-guide/plugins/hooks-and-transactions/http-sessions.en.rst
b/doc/developer-guide/plugins/hooks-and-transactions/http-sessions.en.rst
index d994989..cd9fcb9 100644
--- a/doc/developer-guide/plugins/hooks-and-transactions/http-sessions.en.rst
+++ b/doc/developer-guide/plugins/hooks-and-transactions/http-sessions.en.rst
@@ -49,7 +49,7 @@ Use the session hooks to get a handle to a session (an
``TSHttpSsn``
object). If you want your plugin to be called back for each transaction
within the session, then use ``TSHttpSsnHookAdd``.
-**Note:** you must reenable the session with ``TSHttpSsnReenable`` after
+**Note:** you must re-enable the session with ``TSHttpSsnReenable`` after
processing a session hook.
The session hook functions are listed below:
diff --git
a/doc/developer-guide/plugins/hooks-and-transactions/ssl-hooks.en.rst
b/doc/developer-guide/plugins/hooks-and-transactions/ssl-hooks.en.rst
index b5c91d3..cf9dd41 100644
--- a/doc/developer-guide/plugins/hooks-and-transactions/ssl-hooks.en.rst
+++ b/doc/developer-guide/plugins/hooks-and-transactions/ssl-hooks.en.rst
@@ -40,7 +40,7 @@ The following actions are valid from these callbacks.
* Fetch the SSL object associated with the connection -
:c:func:`TSVConnSslConnectionGet`
* Set a connection to blind tunnel - :c:func:`TSVConnTunnel`
- * Reenable the ssl connection - :c:func:`TSVConnReenable`
+ * Re-enable the ssl connection - :c:func:`TSVConnReenable`
* Find SSL context by name - :c:func:`TSSslContextFindByName`
* Find SSL context by address - :c:func:`TSSslContextFindByAddr`
* Determine whether the TSVConn is really representing a SSL connection -
:c:func:`TSVConnIsSsl`
@@ -63,7 +63,7 @@ TS_VCONN_CLOSE_HOOK
------------------------
This hook is invoked after the SSL handshake is done and when the IO is
closing. The TSVConnArgs
-should be cleaned up here. A callback at this point must reenable.
+should be cleaned up here. A callback at this point must re-enable.
TS_SSL_CLIENT_HELLO_HOOK
------------------------
@@ -145,7 +145,7 @@ TS_VCONN_OUTBOUND_CLOSE_HOOK
-----------------------------
This hook is invoked after the SSL handshake is done and right before the
outbound connection
-closes. A callback at this point must reenable.
+closes. A callback at this point must re-enable.
TLS Inbound Hook State Diagram
------------------------------
diff --git
a/doc/developer-guide/plugins/hooks-and-transactions/trafficserver-timers.en.rst
b/doc/developer-guide/plugins/hooks-and-transactions/trafficserver-timers.en.rst
index 849be22..f99f3bf 100644
---
a/doc/developer-guide/plugins/hooks-and-transactions/trafficserver-timers.en.rst
+++
b/doc/developer-guide/plugins/hooks-and-transactions/trafficserver-timers.en.rst
@@ -22,7 +22,7 @@ Transaction Timers at various states
------------------------------------
Traffic Server runs a variety of timers at various states of a transaction.
Typically,
-a given transaction may include upto two connections (one on the UA/client
side and the
+a given transaction may include up to two connections (one on the UA/client
side and the
other on the Origin side). Traffic Server supports two kinds of timers
"Active" and
"Inactive" timers for each side respectively, as applicable at a given state.
The below
picture illustrates the specific timers run at various states in the current
implementation.
diff --git a/doc/developer-guide/plugins/http-transformations/index.en.rst
b/doc/developer-guide/plugins/http-transformations/index.en.rst
index e70c74d..6e057dc 100644
--- a/doc/developer-guide/plugins/http-transformations/index.en.rst
+++ b/doc/developer-guide/plugins/http-transformations/index.en.rst
@@ -125,7 +125,7 @@ VIOs
A ``VIO`` or virtual IO is a description of an in progress IO
operation. The ``VIO`` data structure is used by ``VConnection`` users
to determine how much progress has been made on a particular IO
-operation, and to reenable an IO operation when it stalls due to buffer
+operation, and to re-enable an IO operation when it stalls due to buffer
space. ``VConnection`` implementers use ``VIO``\ s to determine the
buffer for an IO operation, how much work to do on the IO operation, and
which continuation to call back when progress on the IO operation is
diff --git
a/doc/developer-guide/plugins/http-transformations/sample-null-transformation-plugin.en.rst
b/doc/developer-guide/plugins/http-transformations/sample-null-transformation-plugin.en.rst
index c6c20e7..86a2400 100644
---
a/doc/developer-guide/plugins/http-transformations/sample-null-transformation-plugin.en.rst
+++
b/doc/developer-guide/plugins/http-transformations/sample-null-transformation-plugin.en.rst
@@ -150,7 +150,7 @@ Below is an overview of the null transform plugin:
10. If there is more data left to read ( if ndone < nbytes), then the
``handle_transform`` function wakes up the downstream vconnection
- with a reenable and wakes up the upstream vconnection by sending it
+ with a re-enable and wakes up the upstream vconnection by sending it
``WRITE_READY``:
.. code-block:: c
@@ -167,7 +167,7 @@ Below is an overview of the null transform plugin:
The process of passing data through the transformation is
illustrated in the following diagram. The downstream vconnections
send ``WRITE_READY`` events when they need more data; when data is
- available, the upstream vconnections reenable the downstream
+ available, the upstream vconnections re-enable the downstream
vconnections. In this instance, the ``TSVIOReenable`` function sends
``TS_EVENT_IMMEDIATE``.
@@ -182,7 +182,7 @@ Below is an overview of the null transform plugin:
11. If the ``handle_transform`` function finds there is no more data to
read, then it sets ``nbytes`` to ``ndone`` on the output
(downstream) VIO and wakes up the output vconnection with a
- reenable. It then triggers the end of the write operation from the
+ re-enable. It then triggers the end of the write operation from the
upstream vconnection by sending the upstream vconnection a
``WRITE_COMPLETE`` event.
diff --git a/doc/developer-guide/plugins/mutexes.en.rst
b/doc/developer-guide/plugins/mutexes.en.rst
index ae59e41..74a39f2 100644
--- a/doc/developer-guide/plugins/mutexes.en.rst
+++ b/doc/developer-guide/plugins/mutexes.en.rst
@@ -339,7 +339,7 @@ case only, it's safe to access data shared between ``txnp``
and
HTTP transaction ``txnp`` is the only one that will call back
``txn_contp``, and you are guaranteed that ``txn_contp`` will be called
back only one hook at a time. After processing is finished,
-``txn_contp`` will reenable ``txnp``.
+``txn_contp`` will re-enable ``txnp``.
In all other cases, you should create a mutex with the continuation. In
general, a lock is needed when you're using iocore APIs or any other API
diff --git a/doc/developer-guide/release-process/index.en.rst
b/doc/developer-guide/release-process/index.en.rst
index ef7e4e7..83eb950 100644
--- a/doc/developer-guide/release-process/index.en.rst
+++ b/doc/developer-guide/release-process/index.en.rst
@@ -94,7 +94,7 @@ Distribute
==========
The release candidate files should be uploaded to some public storage. Your
-personal storage on *people.apach.org* is a reasonable location to use.
+personal storage on *people.apache.org* is a reasonable location to use.
Send the release candidate announcement to the *users* and *dev* mailing
lists, noting that it is a release *candidate* and providing a link to the
diff --git a/doc/developer-guide/threads-and-events.en.rst
b/doc/developer-guide/threads-and-events.en.rst
index 3761b88..314080b 100644
--- a/doc/developer-guide/threads-and-events.en.rst
+++ b/doc/developer-guide/threads-and-events.en.rst
@@ -133,7 +133,7 @@ Types
.. function:: start(const char * name, void * stack, size_t stacksize,
ThreadFunction const &f)
- Start the underyling thread. It is given the name :arg:`name`. If
:arg:`stack` is
+ Start the underlying thread. It is given the name :arg:`name`. If
:arg:`stack` is
:code:`nullptr` then a stack is allocated for it of size
:arg:`stacksize`. Once the thread is
started, :arg:`f` is invoked in the context of the thread if non
:code:`nullptr`, otherwise
the method :func:`Thread::execute` is called. The thread execution
returns immediately after
