Fixed spelling mistakes in the docs

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

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".
 
 ::
 

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 *

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`.

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

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
 ~~~~~~

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.
 

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.

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

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.

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.
 

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.

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.

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

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
 -------------

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

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*

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}`.
 

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.

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.

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:

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
 ------------------------------

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.

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

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.
 

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

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

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