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 <[email protected]>
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
