trafficserver-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@apache.org
Subject [trafficserver] branch master updated: More doc spelling fixes
Date Fri, 09 Aug 2019 18:02:47 GMT
This is an automated email from the ASF dual-hosted git repository.

rrm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/trafficserver.git


The following commit(s) were added to refs/heads/master by this push:
     new bed431c  More doc spelling fixes
bed431c is described below

commit bed431c159fcda35487c6e08ba2f88fa2516d3b8
Author: Randall Meyer <rrm@apache.org>
AuthorDate: Thu Aug 8 14:45:08 2019 -0700

    More doc spelling fixes
---
 doc/admin-guide/files/ip_allow.yaml.en.rst               |  4 ++--
 doc/admin-guide/files/records.config.en.rst              |  4 ++--
 doc/admin-guide/logging/rotation.en.rst                  |  2 +-
 doc/admin-guide/logging/understanding.en.rst             |  2 +-
 doc/admin-guide/plugins/access_control.en.rst            |  2 +-
 doc/admin-guide/plugins/ja3_fingerprint.en.rst           |  4 ++--
 doc/developer-guide/api/functions/TSConfig.en.rst        |  2 +-
 .../api/functions/TSIOBufferReader.en.rst                |  2 +-
 .../api/functions/TSMimeHdrFieldAppend.en.rst            |  2 +-
 .../cache-architecture/tiered-storage.en.rst             |  2 +-
 doc/developer-guide/core-architecture/rpc.en.rst         | 16 ++++++++--------
 .../core-architecture/url_rewrite_architecture.en.rst    |  2 +-
 .../design-documents/reloading-plugins.en.rst            | 14 +++++++-------
 doc/developer-guide/documentation/adding-domains.en.rst  |  2 +-
 doc/developer-guide/documentation/building.en.rst        |  2 +-
 doc/developer-guide/documentation/conventions.en.rst     | 12 ++++++------
 doc/developer-guide/documentation/plugins.en.rst         |  2 +-
 doc/developer-guide/documentation/rst-and-sphinx.en.rst  |  2 +-
 doc/developer-guide/documentation/structure.en.rst       |  2 +-
 doc/developer-guide/documentation/ts-markup.en.rst       |  6 +++---
 doc/developer-guide/internal-libraries/Extendible.en.rst |  2 +-
 doc/developer-guide/testing/blackbox-testing.en.rst      |  6 +++---
 doc/developer-guide/testing/index.en.rst                 |  2 +-
 23 files changed, 48 insertions(+), 48 deletions(-)

diff --git a/doc/admin-guide/files/ip_allow.yaml.en.rst b/doc/admin-guide/files/ip_allow.yaml.en.rst
index c91c3af..e8e98ba 100644
--- a/doc/admin-guide/files/ip_allow.yaml.en.rst
+++ b/doc/admin-guide/files/ip_allow.yaml.en.rst
@@ -131,7 +131,7 @@ The following example allows access to all clients on addresses in a subnet::
 
 The following example denies access all clients on addresses in a subnet::
 
-   apppy: in
+   apply: in
    ip_addrs: 123.45.6.0-123.45.6.123
    action: deny
 
@@ -214,7 +214,7 @@ As a final example, here is the default configuration in compact form::
      { apply: in, ip_addrs: 127.0.0.1, action: allow },
      { apply: in, ip_addrs: "::1", action: allow },
      { apply: in, ip_addrs: 0/0, action: deny, methods: [ PURGE, PUSH, DELETE ] },
-     { apply: in, ip_addrs: "::/0", action: deny, methods: [ PURGE, PUSH, DELTE ] }
+     { apply: in, ip_addrs: "::/0", action: deny, methods: [ PURGE, PUSH, DELETE ] }
      ]
 
 .. note::
diff --git a/doc/admin-guide/files/records.config.en.rst b/doc/admin-guide/files/records.config.en.rst
index 622ca11..b2e79cc 100644
--- a/doc/admin-guide/files/records.config.en.rst
+++ b/doc/admin-guide/files/records.config.en.rst
@@ -287,13 +287,13 @@ System Variables
    While rolling default behavior is to rename, close and re-open the log file *only* when/if
there is
    something to log to the log file. This option opens a new log file right after rolling
even if there
    is nothing to log (i.e. nothing to be logged due to lack of requests to the server)
-   which may lead to 0-sized log files while rollong. See :doc:`../logging/rotation.en` for
an use-case
+   which may lead to 0-sized log files while rolling. See :doc:`../logging/rotation.en` for
an use-case
    for this option.
 
    ===== ======================================================================
    Value Description
    ===== ======================================================================
-   ``0`` No empty log files created and rolloed if there was nothing to log
+   ``0`` No empty log files created and rolled if there was nothing to log
    ``1`` Allow empty log files to be created and  rolled even if there was nothing to log
    ===== ======================================================================
 
diff --git a/doc/admin-guide/logging/rotation.en.rst b/doc/admin-guide/logging/rotation.en.rst
index 64ed337..6dad554 100644
--- a/doc/admin-guide/logging/rotation.en.rst
+++ b/doc/admin-guide/logging/rotation.en.rst
@@ -187,7 +187,7 @@ Retention Options
 
 |TS| enables you to control the amount of disk space that the logging directory
 can consume. This allows the system to operate smoothly within a specified
-space window for a long period of time.  After you establish a space limit,
+space window for a long period of time. After you establish a space limit,
 |TS| continues to monitor the space in the logging directory. When the free
 space dwindles to the headroom limit, it enters a low space state and takes the
 following actions:
diff --git a/doc/admin-guide/logging/understanding.en.rst b/doc/admin-guide/logging/understanding.en.rst
index c6d70b8..6cad223 100644
--- a/doc/admin-guide/logging/understanding.en.rst
+++ b/doc/admin-guide/logging/understanding.en.rst
@@ -83,7 +83,7 @@ specifies where these messages are logged. A typical location is
 
 The :manpage:`syslog(8)` process works on a system-wide basis, so it serves as
 the single repository for messages from all |TS| processes (including
-:program:`traffic_server` and  :program:`traffic_manager`).
+:program:`traffic_server` and :program:`traffic_manager`).
 
 System information logs observe a static format. Each log entry in the log
 contains information about the date and time the error was logged, the hostname
diff --git a/doc/admin-guide/plugins/access_control.en.rst b/doc/admin-guide/plugins/access_control.en.rst
index 7fcf7e5..2aefafb 100644
--- a/doc/admin-guide/plugins/access_control.en.rst
+++ b/doc/admin-guide/plugins/access_control.en.rst
@@ -329,7 +329,7 @@ Plugin configuration
    * ``--include-uri-paths-file`` (`optional`, default:empty/unused) - a file containing
a list of regex expressions to be matched against URI paths. The access control is applied
to paths that match.
    * ``--exclude-uri-paths-file`` (`optional`, default:empty/unused) - a file containing
a list of regex expressions to be matched against URI paths. The access control is applied
to paths that do not match.
 
-* Behavior modificators to support various use-cases
+* Behavior modifiers to support various use-cases
    * ``--reject-invalid-token-requests`` (`optional`, default:``false``) - reject invalid
token requests instead of forwarding them to origin_.
    * ``--use-redirects`` (`optional`, default:``false``) - used to configure `use case 2`_,
not implemented yet.
 
diff --git a/doc/admin-guide/plugins/ja3_fingerprint.en.rst b/doc/admin-guide/plugins/ja3_fingerprint.en.rst
index 351ef3b..931b936 100644
--- a/doc/admin-guide/plugins/ja3_fingerprint.en.rst
+++ b/doc/admin-guide/plugins/ja3_fingerprint.en.rst
@@ -32,11 +32,11 @@ for creating SSL/TLS client fingerprints by concatenating values in the
`TLS Cli
 <https://tools.ietf.org/html/rfc5246#section-7.4.1.2>`__ and hashing the result using
`MD5
 <https://www.openssl.org/docs/man1.1.0/man3/MD5_Init.html>`__ to produce a 32 character
fingerprint.
 A particular instance of malware tends to use the same encryption code/client, which makes
it an
-effective way to detect malicious clients even when superficial details are modifed. More
info about
+effective way to detect malicious clients even when superficial details are modified. More
info about
 JA3 is available `here <https://github.com/salesforce/ja3>`__.
 
 The calculated JA3 fingerprints are then appended to upstream request in the field ``X-JA3-Sig``
-(to be processed at upstream). If multiple dups exist for the field name, it will append
to the last 
+(to be processed at upstream). If multiple duplicates exist for the field name, it will append
to the last 
 occurrence; if none exists, it will add such a field to the headers. The signatures can also
be logged locally.
 
 Plugin Configuration
diff --git a/doc/developer-guide/api/functions/TSConfig.en.rst b/doc/developer-guide/api/functions/TSConfig.en.rst
index d01dd20..0002853 100644
--- a/doc/developer-guide/api/functions/TSConfig.en.rst
+++ b/doc/developer-guide/api/functions/TSConfig.en.rst
@@ -38,7 +38,7 @@ Description
 These functions provide a mechanism to safely update configurations for a plugin.
 
 If a plugin stores its configuration in a data structure, updating that structure due to
changes in
-the configuration file can be dangerous due to the asynchonous nature of plugin callbacks.
To avoid
+the configuration file can be dangerous due to the asynchronous nature of plugin callbacks.
To avoid
 that problem these functions allow a plugin to register a configuration and then later replace
it
 with another instance without changing the instance in use by plugin callbacks. This works
in the
 same manner as `shared pointer <https://en.wikipedia.org/wiki/Smart_pointer>`__. When
a plugin needs
diff --git a/doc/developer-guide/api/functions/TSIOBufferReader.en.rst b/doc/developer-guide/api/functions/TSIOBufferReader.en.rst
index 5febf0c..031eb95 100644
--- a/doc/developer-guide/api/functions/TSIOBufferReader.en.rst
+++ b/doc/developer-guide/api/functions/TSIOBufferReader.en.rst
@@ -69,7 +69,7 @@ time. Reader allocation is fast and cheap until this maximum is reached
at which
    Use :func:`TSIOBufferReaderClone` to get another reader if the buffer is already in use.
 
 :func:`TSIOBufferReaderClone` duplicate a reader.
-   A reader for :arg:`bufp` is allocated and the intial reader position is set to be the
same as
+   A reader for :arg:`bufp` is allocated and the initial reader position is set to be the
same as
    :arg:`reader`.
 
 :func:`TSIOBufferReaderFree` de-allocate :arg:`reader`.
diff --git a/doc/developer-guide/api/functions/TSMimeHdrFieldAppend.en.rst b/doc/developer-guide/api/functions/TSMimeHdrFieldAppend.en.rst
index 7866364..7690fa8 100644
--- a/doc/developer-guide/api/functions/TSMimeHdrFieldAppend.en.rst
+++ b/doc/developer-guide/api/functions/TSMimeHdrFieldAppend.en.rst
@@ -31,7 +31,7 @@ Synopsis
 Description
 ===========
 
-Attatches a MIME :arg:`field` to a header. The header is represented by the :arg:`bufp` and
:arg:`hdr`
+Attaches a MIME :arg:`field` to a header. The header is represented by the :arg:`bufp` and
:arg:`hdr`
 arguments which should have been obtained by a call to :func:`TSHttpTxnClientReqGet` or similar.
If
 the field in :arg:`field` was created by calling :func:`TSMimeHdrFieldCreateNamed` the same
 :arg:`bufp` and :arg:`hdr` passed to that should be passed to this function.
diff --git a/doc/developer-guide/cache-architecture/tiered-storage.en.rst b/doc/developer-guide/cache-architecture/tiered-storage.en.rst
index 2448e97..18399f7 100644
--- a/doc/developer-guide/cache-architecture/tiered-storage.en.rst
+++ b/doc/developer-guide/cache-architecture/tiered-storage.en.rst
@@ -110,7 +110,7 @@ This means, among other things, that if there is a tier with the object
all
 other tiers that are written will get a local copy of the object, and the origin
 server will not be used. In terms of implementation, currently a cache write to
 a volume is done via the construction of an instance of :cpp:class:`CacheVC`
-which receieves the object stream. For tiered storage, the same thing is done
+which receives the object stream. For tiered storage, the same thing is done
 for each target volume.
 
 For cache volume overrides (via :file:`hosting.config`) this same process is
diff --git a/doc/developer-guide/core-architecture/rpc.en.rst b/doc/developer-guide/core-architecture/rpc.en.rst
index 1e43989..f447b10 100644
--- a/doc/developer-guide/core-architecture/rpc.en.rst
+++ b/doc/developer-guide/core-architecture/rpc.en.rst
@@ -57,7 +57,7 @@ Runtime Structure
    [traffic_manager] <-r-> [traffic_server] : Local RPC
    [traffic_server] <-r-> [plugin] : Hook
 
-|TManager| opens a unix domain socket to recieve commands from remote clients. |TManager|
also has a unix domain socket connection with |TServer| to communicate.
+|TManager| opens a unix domain socket to receive commands from remote clients. |TManager|
also has a unix domain socket connection with |TServer| to communicate.
 
 ===============
 Message Passing
@@ -69,7 +69,7 @@ Sequence diagram for a command sent from |TCtl| to when it is received by
a plug
 
 .. note::
 
-    Currently a fire and forget model. traffic_manager sends out an asynchoronous signal
without any acknowledgement. It then proceeds to send a response itself.
+    Currently a fire and forget model. traffic_manager sends out an asynchronous  signal
without any acknowledgment. It then proceeds to send a response itself.
 
 =======================
 Remote RPC vs Local RPC
@@ -92,7 +92,7 @@ Serialization Mechanism
     - **MGMT_MARSHALL_STRING** : 4 bytes to indicate the string size in bytes, followed by
the entire string and NULL terminator.
     - **MGMT_MARSHALL_DATA** : 4 byt es to indicate data size in bytes, followed by the entire
data object.
 
-When data is actually sent over a connection it must first be seralized. This is the general
serialization mechanism for RPC communcation.
+When data is actually sent over a connection it must first be serialized. This is the general
serialization mechanism for RPC communication.
 
 Generally, for remote clients sending messages to |TServer|, the message is serialized using
remote RPC APIs. The serialized message is sent to |TManager| and |TManager| then simply relays
the message to |TServer|. |TServer| eventually unserializes the message.
 
@@ -103,7 +103,7 @@ Marshalling:
 
    .. function:: ssize_t mgmt_message_marshall(void *buf, size_t remain, const MgmtMarshallType
*fields, unsigned count, ...)
 
-      Variable argument wrapper for ``mgmt_message_marshall_v``. Allows for different datatypes
to be marshalled together as long as a field is specified for each data object. Arguments
should be references to objects to be marshalled.
+      Variable argument wrapper for ``mgmt_message_marshall_v``. Allows for different data
types to be marshalled together as long as a field is specified for each data object. Arguments
should be references to objects to be marshalled.
 
    .. function:: ssize_t mgmt_message_marshall_v(void *buf, size_t remain, const MgmtMarshallType
*fields, unsigned count, va_list ap)
 
@@ -114,7 +114,7 @@ Unmarshalling:
 
    .. function:: ssize_t mgmt_message_parse(const void *buf, size_t len, const MgmtMarshallType
*fields, unsigned count, ...)
 
-      Variable argument wrapper for ``mgmt_message_parse_v``. Reference to data object to
store unmarshalled message needed for variable arguements.
+      Variable argument wrapper for ``mgmt_message_parse_v``. Reference to data object to
store unmarshalled message needed for variable arguments.
 
    .. function:: ssize_t mgmt_message_parse_v(const void *buf, size_t len, const MgmtMarshallType
*fields, unsigned count, va_list ap)
 
@@ -124,7 +124,7 @@ Unmarshalling:
 Local Serialization
 ===================
 
-A RPC message is sent as a :class:`MgmtMessageHdr` followed by the serialized data in bytes.
Serialization is very simple as the inteface for communication between |TManager| and |TServer|
only allows for :class:`MgmtMessageHdr`, which is a fixed size, and raw data in the form of
:code:`char*` to be sent. A header specifies a :arg:`msg_id` and the :arg:`data_len`. On a
read, the header is *always* first read. Based on the length of the data payload, the correct
number of bytes is then re [...]
+A RPC message is sent as a :class:`MgmtMessageHdr` followed by the serialized data in bytes.
Serialization is very simple as the interface for communication between |TManager| and |TServer|
only allows for :class:`MgmtMessageHdr`, which is a fixed size, and raw data in the form of
:code:`char*` to be sent. A header specifies a :arg:`msg_id` and the :arg:`data_len`. On a
read, the header is *always* first read. Based on the length of the data payload, the correct
number of bytes is then r [...]
 
 .. class:: MgmtMessageHdr
 
@@ -168,7 +168,7 @@ RPC API for remote clients
 
 :ts:git:`NetworkMessage.cc` provides a set of APIs for remote clients to communicate with
|TManager|.
 
-|TManager| will then send a response with the return value. The return value only indicates
if the request was successfully propogated to |TServer|. Thus, there is no way currently for
|TServer| to send information back to remote clients.
+|TManager| will then send a response with the return value. The return value only indicates
if the request was successfully propagated to |TServer|. Thus, there is no way currently for
|TServer| to send information back to remote clients.
 
 .. function:: TSMgmtError send_mgmt_request(const mgmt_message_sender &snd, OpType optype,
...)
 .. function:: TSMgmtError send_mgmt_request(int fd, OpType optype, ...)
@@ -234,7 +234,7 @@ RPC API for |TServer| and |TManager|
 .. figure:: ../../uml/images/RPC-states.svg
    :align: center
 
-|LM| and |PM| follow similar workflows. A manager will poll the socket for any messages.
If it is able to read a message, it will handle it based on the :arg:`msg_id` from the :class:`MgmtMessageHdr`
and select a callback to run asynchoronously. The async callback will add a response, if any,
to an outgoing event queue within the class. A manager will continue to poll and read on the
socket as long as there are messages avaliable. Two things can stop a manager from polling.
+|LM| and |PM| follow similar workflows. A manager will poll the socket for any messages.
If it is able to read a message, it will handle it based on the :arg:`msg_id` from the :class:`MgmtMessageHdr`
and select a callback to run asynchoronously. The async callback will add a response, if any,
to an outgoing event queue within the class. A manager will continue to poll and read on the
socket as long as there are messages available. Two things can stop a manager from polling.
 
 1. there are no longer any messages on the socket for a *timeout* time period.
 
diff --git a/doc/developer-guide/core-architecture/url_rewrite_architecture.en.rst b/doc/developer-guide/core-architecture/url_rewrite_architecture.en.rst
index 2e1870d..5a50a4d 100644
--- a/doc/developer-guide/core-architecture/url_rewrite_architecture.en.rst
+++ b/doc/developer-guide/core-architecture/url_rewrite_architecture.en.rst
@@ -53,7 +53,7 @@ Implementation
 
       A container for a regular expression mapping. This contains the base mapping along
with the
       regular expression and a format string. The format string is annotated with the locations
of
-      regular expression match group subsitutions so that if the regular expression matches,
the
+      regular expression match group substitutions so that if the regular expression matches,
the
       results can be efficiently assembled in to the output host name.
 
 .. figure:: /uml/images/url_rewrite.svg
diff --git a/doc/developer-guide/design-documents/reloading-plugins.en.rst b/doc/developer-guide/design-documents/reloading-plugins.en.rst
index c3cf61d..23f96e0 100644
--- a/doc/developer-guide/design-documents/reloading-plugins.en.rst
+++ b/doc/developer-guide/design-documents/reloading-plugins.en.rst
@@ -23,9 +23,9 @@ Reloading Plugins
 *****************
 
 Reloading plugin allows new versions of a plugin code to be loaded and executed and old versions
to be unloaded without
-restarting the traffic server process.
+restarting the |TS| process.
 
-Plugins are Dynamic Shared Objects (DSO), new versions of the plugins are currently loaded
by using a traffic server
+Plugins are Dynamic Shared Objects (DSO), new versions of the plugins are currently loaded
by using a |TS|
 configuration reload, i.e.::
 
   traffic_ctl config reload
@@ -40,12 +40,12 @@ Design Considerations
 1. The mechanism of the plugin reload should be transparent to the plugin developers, plugin
developers should be
    concerned only with properly initializing and cleaning up after the plugin and its instances.
 
-2. With the current traffic server implementation new version plugin (re)load is only triggered
by a configuration
+2. With the current |TS| implementation new version plugin (re)load is only triggered by
a configuration
    (re)load hence naturally the configuration should be always coupled with the set of plugins
it loaded.
 
-3. Due to its asynchronouse nature traffic server should allow running different newer and
older versions of the same plugin at the same time.
+3. Due to its asynchronous nature, |TS| should allow running different newer and older versions
of the same plugin at the same time.
 
-4. Old plugin versions should be unloaded after the traffic server process no longer needs
them after reload.
+4. Old plugin versions should be unloaded after the |TS| process no longer needs them after
reload.
 
 5. Running different versions of the configuration and plugin versions at the same time requires
maintaining
    a "current active set" to be used by new transactions, new continuations, etc. and also
multiple "previous inactive" sets as well.
@@ -130,7 +130,7 @@ the reference counting and when continuations are destroyed or handle
events.
 TSHttpArgs
 ----------
 
-Traffic Server sessions and transactions provide a fixed array of void pointers that can
be used by plugins
+|TS| sessions and transactions provide a fixed array of void pointers that can be used by
plugins
 to store information. To avoid collisions between plugins a plugin should first *reserve*
an index in the array.
 
 Since :c:func:`TSHttpTxnArgIndexReserve` and :c:func:`TSHttpSsnArgIndexReserve` are meant
to be called during plugin
@@ -174,5 +174,5 @@ be reused by 'global' plugins in the future.
 
 
 To make sure plugins are still loaded while their code is still in use there is reference
counting done around ``PluginDso``
-which inherits ``RefCountObj`` and implements ``aqcuire()`` and ``release()`` methods which
are called by ``TSCreateCont``,
+which inherits ``RefCountObj`` and implements ``acquire()`` and ``release()`` methods which
are called by ``TSCreateCont``,
 ``TSVConnCreate`` and ``TSDestroyCont``.
diff --git a/doc/developer-guide/documentation/adding-domains.en.rst b/doc/developer-guide/documentation/adding-domains.en.rst
index bef4d78..16afe6c 100644
--- a/doc/developer-guide/documentation/adding-domains.en.rst
+++ b/doc/developer-guide/documentation/adding-domains.en.rst
@@ -65,7 +65,7 @@ will construct classes which allow us to document variables thusly::
     .. ts:variable:: http_enabled http integer
        :deprecated:
 
-       Enables (any postive, non-zero value) or disables (any zero or negative
+       Enables (any positive, non-zero value) or disables (any zero or negative
        value) processing of HTTP requests.
 
 And referencing of those variables defined with this domain via::
diff --git a/doc/developer-guide/documentation/building.en.rst b/doc/developer-guide/documentation/building.en.rst
index 9e5cedc..51df0e6 100644
--- a/doc/developer-guide/documentation/building.en.rst
+++ b/doc/developer-guide/documentation/building.en.rst
@@ -76,7 +76,7 @@ directory of the |TS| source tree)::
 
     make clean && make html
 
-This will ensure that make doesn't inadvertantly skip the regeneration of any
+This will ensure that make doesn't inadvertently skip the regeneration of any
 targets.
 
 .. note::
diff --git a/doc/developer-guide/documentation/conventions.en.rst b/doc/developer-guide/documentation/conventions.en.rst
index 6a6c6bb..9b269c2 100644
--- a/doc/developer-guide/documentation/conventions.en.rst
+++ b/doc/developer-guide/documentation/conventions.en.rst
@@ -64,7 +64,7 @@ Bracketed Monospace
     Example::
 
         To examine a performance statistic of a running |TS| instance, you may
-        run the comand ``traffic_ctl metric get <name>``, replacing ``<name>``
with
+        run the command ``traffic_ctl metric get <name>``, replacing ``<name>``
with
         the statistic you wish to examine.
 
 Ellipsis
@@ -87,7 +87,7 @@ Notes
 Important Notes
     The use of ``.. important::`` callout blocks should be limited only to those
     situations in which critical information needs to be prominently displayed.
-    Suitable use would include noting that resizing a cache voiume will result
+    Suitable use would include noting that resizing a cache volume will result
     in |TS| resetting the cache contents to empty when the service is started.
     This is information that may not be obvious, or safe to assume, for the
     reader but which can significantly (and negatively) impact the use and
@@ -114,7 +114,7 @@ Definition Lists
     any series of terms need to be explained outside of the formal glossary.
 
 Ordered Lists
-    Explicityly numbered ordered lists should be avoided. |RST| provides two
+    Explicitly numbered ordered lists should be avoided. |RST| provides two
     methods of marking up ordered, numbered lists, and the automatic numbering
     form should be used in all cases where surrounding paragraphs do not need
     to reference individual list entries.
@@ -135,7 +135,7 @@ the cell content cannot be wrapped because there are no breaking spaces
present
 underscores, dashes, and so no, but no whitespace), the table may still require
 overflowing into the page margin. Whenever possible, please try to avoid the
 use of tables when presenting information that will lead to this, as it greatly
-hampers readibility on smaller screens, especially tablets and mobile devices.
+hampers readability on smaller screens, especially tablets and mobile devices.
 Alternatives such as a definition list may be better suited to the content.
 
 Tables may be marked up using any of the |RST| styles, though it is generally
@@ -152,7 +152,7 @@ and shortcut listing in the file ``doc/common.defs``. This file should
be
 included by all |RST| source files after the standard project copyright notice.
 
 The file should always be included using a relative path from the current file's
-location. Any commonly or repeatedly used abbreviations, especialy those of
+location. Any commonly or repeatedly used abbreviations, especially those of
 product, company, or person names, should be added to the definitions file as
 useful to avoid repetitive typing and ensure accurate spellings or legal usage.
 
@@ -206,7 +206,7 @@ resource, that reference is more ideally integrated as a standard |RST|
 reference.
 
 For more descriptive content that might have been included as a footnote, it is
-less disruptive and more useful to choose between reformullating the text to
+less disruptive and more useful to choose between reformatting the text to
 simply include the additional wording, or consider the use of an inline note
 block.
 
diff --git a/doc/developer-guide/documentation/plugins.en.rst b/doc/developer-guide/documentation/plugins.en.rst
index 4257a11..854ab33 100644
--- a/doc/developer-guide/documentation/plugins.en.rst
+++ b/doc/developer-guide/documentation/plugins.en.rst
@@ -39,7 +39,7 @@ Introduction
 ------------
 
 A brief section in which the plugin's core functionality is explained in a
-quickly digestable paragraph or two. For the sake of brevity, this section
+quickly digestible paragraph or two. For the sake of brevity, this section
 should omit discussion of configuration details in favor of providing a more
 10,000 foot view of the plugin features.
 
diff --git a/doc/developer-guide/documentation/rst-and-sphinx.en.rst b/doc/developer-guide/documentation/rst-and-sphinx.en.rst
index 22070ca..6cf2f1d 100644
--- a/doc/developer-guide/documentation/rst-and-sphinx.en.rst
+++ b/doc/developer-guide/documentation/rst-and-sphinx.en.rst
@@ -28,7 +28,7 @@ final rendered forms. While not entirely dissimilar to other plain text
markup
 formats like Markdown, RST provides additional functionality for defining
 internal links between documents, producing tables of contents, and indices.
 Additionally, RST works in hand with Sphinx for providing advanced features
-such as markup domains, of which this documenentation makes extensive use.
+such as markup domains, of which this documentation makes extensive use.
 
 Both |RST| and Sphinx have official documentation resources which detail their
 full capabilities and all markup options, as well as methods of extending them
diff --git a/doc/developer-guide/documentation/structure.en.rst b/doc/developer-guide/documentation/structure.en.rst
index 45787d9..c0edbb5 100644
--- a/doc/developer-guide/documentation/structure.en.rst
+++ b/doc/developer-guide/documentation/structure.en.rst
@@ -35,7 +35,7 @@ Preface
 Getting Started
     Aimed at administrators and developers new to |TS| who wish to install and
     configure a |TS| instance in the least amount of time necessary, without
-    delving into the full featureset or the internals of the |TS| architecture.
+    delving into the full feature set or the internals of the |TS| architecture.
 
 Administrator's Guide
     Provides in-depth coverage of all |TS| features and configurations for use
diff --git a/doc/developer-guide/documentation/ts-markup.en.rst b/doc/developer-guide/documentation/ts-markup.en.rst
index 10a40c0..b697351 100644
--- a/doc/developer-guide/documentation/ts-markup.en.rst
+++ b/doc/developer-guide/documentation/ts-markup.en.rst
@@ -86,13 +86,13 @@ Data Type
 Value
     The default value of the configuration variable. It is preferable to not
     use any order of magnitude suffix, as |TS| will rewrite its configuration
-    files under varioua circumstances, and when doing so it does not maintain
+    files under various circumstances, and when doing so it does not maintain
     those suffixes.
 
 Options
 ~~~~~~~
 
-The domain for configuration variables takes serveral options.
+The domain for configuration variables takes several options.
 
 reloadable
    If marked the effect of the variable can be changed by reloading the |TS| configuration.
@@ -175,7 +175,7 @@ type
 
     :literal:`derivative`
         Statistics of this type presents values that are calculated, or derived,
-        from other staistics. They do not expose a number or state gathered
+        from other statistics. They do not expose a number or state gathered
         directly. Typical statistics of this type are representations of a
         statistic over a given period (e.g. average origin connections per
         second), ratio or percentage of a statistic as part of a set (e.g. the
diff --git a/doc/developer-guide/internal-libraries/Extendible.en.rst b/doc/developer-guide/internal-libraries/Extendible.en.rst
index c8850f1..26e0392 100644
--- a/doc/developer-guide/internal-libraries/Extendible.en.rst
+++ b/doc/developer-guide/internal-libraries/Extendible.en.rst
@@ -290,7 +290,7 @@ Namespace `ext`
 
    Depends on usage of `super_type` in each class.
 
-   :tparam Derived_t: The class to analyse.
+   :tparam Derived_t: The class to analyze.
 
 .. function:: template <typename T> std::string toString(T const &t)
 
diff --git a/doc/developer-guide/testing/blackbox-testing.en.rst b/doc/developer-guide/testing/blackbox-testing.en.rst
index 1c21bf3..0542d97 100644
--- a/doc/developer-guide/testing/blackbox-testing.en.rst
+++ b/doc/developer-guide/testing/blackbox-testing.en.rst
@@ -151,7 +151,7 @@ Origin Server
   - ip - option to specify IP address. Defaults to ``127.0.0.1``.
   - delay - option to have MicroServer delay for set amount of seconds before returning response.
Defaults to ``0``. 
   - ssl - option to enable SSL 
-  - lookup_key - option to change the unique idenitfier that MicroServer uses to identify
each transaction. Defaults to ``PATH``.
+  - lookup_key - option to change the unique identifier that MicroServer uses to identify
each transaction. Defaults to ``PATH``.
   - clientcert - path to cert used for SSL. Defaults to the included cert in ``tests/tools/microserver/ssl``.
   - clientkey - path to key used for SSL. Same default as above. 
 
@@ -159,7 +159,7 @@ This function returns a AuTest process object that launches the python-based
Mic
 Microserver is a mock server which responds to client http requests. 
 Microserver needs to be setup for the tests that require an origin server behind ATS. 
 The server reads a JSON-formatted data file that contains request headers and the corresponding
response headers. 
-Microserver responds with payload if the response header contains Content-Length or Transfer-Enconding
specified.
+Microserver responds with payload if the response header contains Content-Length or Transfer-Encoding
specified.
 
 - ``Test.addResponse(filename, request_header, response_header)``
 
@@ -193,7 +193,7 @@ DNS
   - filename - file containing zone information for MicroDNS to read from. Defaults to ``dns_file.json``
   - port - option for the DNS port. Autoselected if left unspecified.
   - ip - option for IP address. Defaults to ``127.0.0.1``
-  - rr - option to enable round robining IP. Defaults to ``False``
+  - rr - option to enable round robin IP. Defaults to ``False``
   - default - option to specify a default IP response when MicroDNS can't find a domain:IP
pair. 
 
 - ``dns.addRecords(records, jsonFile)``
diff --git a/doc/developer-guide/testing/index.en.rst b/doc/developer-guide/testing/index.en.rst
index acdd232..2cac843 100644
--- a/doc/developer-guide/testing/index.en.rst
+++ b/doc/developer-guide/testing/index.en.rst
@@ -25,4 +25,4 @@ Testing Traffic Server
 .. toctree::
    :maxdepth: 2
 
-   blackbox-testing.en
\ No newline at end of file
+   blackbox-testing.en


Mime
View raw message