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 fa10c20 Fixes spelling in doc
fa10c20 is described below
commit fa10c20b8ed43072fd7e214c62b195b525f24d8e
Author: Randall Meyer <[email protected]>
AuthorDate: Tue Apr 30 09:08:30 2019 -0700
Fixes spelling in doc
---
doc/.tx/config | 6 ++---
...-caching.en.rst => hierarchical-caching.en.rst} | 0
doc/admin-guide/configuration/index.en.rst | 2 +-
.../configuration/proxy-protocol.en.rst | 4 ++--
.../configuration/redirecting-http-requests.en.rst | 2 +-
doc/admin-guide/files/cache.config.en.rst | 4 ++--
doc/admin-guide/files/ip_allow.config.en.rst | 6 ++---
doc/admin-guide/files/parent.config.en.rst | 2 +-
doc/admin-guide/files/records.config.en.rst | 26 +++++++++++-----------
doc/admin-guide/files/remap.config.en.rst | 2 +-
doc/admin-guide/files/ssl_server_name.yaml.en.rst | 10 ++++-----
doc/admin-guide/files/storage.config.en.rst | 2 +-
doc/admin-guide/installation/index.en.rst | 2 +-
doc/admin-guide/layer-4-routing.en.rst | 4 ++--
doc/admin-guide/logging/formatting.en.rst | 6 ++---
doc/admin-guide/logging/understanding.en.rst | 2 +-
.../monitoring/statistics/accessing.en.rst | 2 +-
doc/admin-guide/performance/index.en.rst | 12 +++++-----
doc/admin-guide/plugins/access_control.en.rst | 6 ++---
doc/admin-guide/plugins/buffer_upload.en.rst | 4 ++--
doc/admin-guide/plugins/cachekey.en.rst | 14 ++++++------
doc/admin-guide/plugins/certifier.en.rst | 2 +-
doc/admin-guide/plugins/compress.en.rst | 2 +-
doc/admin-guide/plugins/escalate.en.rst | 2 +-
doc/admin-guide/plugins/esi.en.rst | 4 ++--
doc/admin-guide/plugins/fq_pacing.en.rst | 2 +-
doc/admin-guide/plugins/header_rewrite.en.rst | 2 +-
doc/admin-guide/plugins/hook-trace.en.rst | 2 +-
doc/admin-guide/plugins/lua.en.rst | 18 +++++++--------
doc/admin-guide/plugins/metalink.en.rst | 2 +-
doc/admin-guide/plugins/money_trace.en.rst | 2 +-
doc/admin-guide/plugins/prefetch.en.rst | 8 +++----
doc/admin-guide/plugins/regex_remap.en.rst | 2 +-
doc/admin-guide/plugins/regex_revalidate.en.rst | 2 +-
doc/admin-guide/plugins/s3_auth.en.rst | 4 ++--
doc/admin-guide/plugins/slice.en.rst | 4 ++--
doc/admin-guide/plugins/ssl_session_reuse.en.rst | 10 ++++-----
doc/admin-guide/plugins/sslheaders.en.rst | 2 +-
doc/admin-guide/plugins/tcpinfo.en.rst | 4 ++--
doc/admin-guide/plugins/url_sig.en.rst | 2 +-
doc/admin-guide/plugins/xdebug.en.rst | 2 +-
doc/admin-guide/security/index.en.rst | 4 ++--
doc/admin-guide/storage/index.en.rst | 2 +-
.../command-line/traffic_cache_tool.en.rst | 2 +-
doc/appendices/command-line/traffic_ctl.en.rst | 6 ++---
doc/appendices/command-line/traffic_logcat.en.rst | 2 +-
doc/appendices/command-line/traffic_wccp.en.rst | 2 +-
doc/appendices/faq.en.rst | 2 +-
.../api/functions/TSHttpHookAdd.en.rst | 2 +-
.../api/functions/TSHttpParserCreate.en.rst | 2 +-
.../api/functions/TSInstallDirGet.en.rst | 2 +-
.../api/functions/TSLifecycleHookAdd.en.rst | 2 +-
.../api/functions/TSMimeHdrFieldAppend.en.rst | 2 +-
.../functions/TSMimeHdrFieldValueStringGet.en.rst | 2 +-
.../api/functions/TSSslContext.en.rst | 2 +-
.../api/functions/TSSslServerContextCreate.en.rst | 2 +-
.../api/functions/TSSslSession.en.rst | 6 ++---
doc/developer-guide/api/functions/TSTypes.en.rst | 6 ++---
.../api/functions/TSUuidCreate.en.rst | 2 +-
.../api/functions/TSVConnReenable.en.rst | 2 +-
doc/developer-guide/api/types/TSMgmtTypes.en.rst | 2 +-
.../cache-architecture/architecture.en.rst | 12 +++++-----
.../cache-architecture/cache-initialization.en.rst | 4 ++--
.../cache-architecture/consistency.en.rst | 2 +-
.../cache-architecture/data-structures.en.rst | 6 ++---
.../cache-architecture/tiered-storage.en.rst | 2 +-
.../client-session-architecture.en.rst | 8 +++----
doc/developer-guide/config-vars.en.rst | 12 +++++-----
doc/developer-guide/debugging/debug-tags.en.rst | 2 +-
.../host-resolution-proposal.en.rst | 4 ++--
.../internal-libraries/AcidPtr.en.rst | 2 +-
.../internal-libraries/MemArena.en.rst | 4 ++--
.../internal-libraries/TextView.en.rst | 2 +-
.../internal-libraries/buffer-writer.en.rst | 22 +++++++++---------
.../internal-libraries/intrusive-hash-map.en.rst | 6 ++---
.../internal-libraries/intrusive-list.en.rst | 2 +-
.../internal-libraries/scalar.en.rst | 16 ++++++-------
.../plugins/example-plugins/tls_bridge.en.rst | 8 +++----
.../http-transactions.en.rst | 4 ++--
.../plugins/hooks-and-transactions/index.en.rst | 2 +-
.../initiate-http-connection.en.rst | 2 +-
.../hooks-and-transactions/ssl-session-api.en.rst | 2 +-
.../plugins/http-headers/mime-headers.en.rst | 2 +-
.../append-transform-plugin.en.rst | 2 +-
.../plugins/http-transformations/index.en.rst | 4 ++--
.../sample-null-transformation-plugin.en.rst | 2 +-
.../plugins/io/transformations.en.rst | 6 ++---
doc/developer-guide/plugins/io/vios.en.rst | 2 +-
doc/developer-guide/plugins/mutexes.en.rst | 4 ++--
doc/developer-guide/release-process/index.en.rst | 2 +-
.../testing-with-vagrant/index.en.rst | 2 +-
doc/developer-guide/threads-and-events.en.rst | 10 ++++-----
doc/getting-started/index.en.rst | 2 +-
93 files changed, 206 insertions(+), 206 deletions(-)
diff --git a/doc/.tx/config b/doc/.tx/config
index 6640ca1..250615d 100644
--- a/doc/.tx/config
+++ b/doc/.tx/config
@@ -37,9 +37,9 @@ file_filter =
locale/<lang>/LC_MESSAGES/admin-guide/configuration/explicit-forwa
source_file =
_build/locale/pot/admin-guide/configuration/explicit-forward-proxying.en.pot
source_lang = en
-[apache-traffic-server-6x.admin-guide--configuration--hierachical-caching_en]
-file_filter =
locale/<lang>/LC_MESSAGES/admin-guide/configuration/hierachical-caching.en.po
-source_file =
_build/locale/pot/admin-guide/configuration/hierachical-caching.en.pot
+[apache-traffic-server-6x.admin-guide--configuration--hierarchical-caching_en]
+file_filter =
locale/<lang>/LC_MESSAGES/admin-guide/configuration/hierarchical-caching.en.po
+source_file =
_build/locale/pot/admin-guide/configuration/hierarchical-caching.en.pot
source_lang = en
[apache-traffic-server-6x.admin-guide--configuration--index_en]
diff --git a/doc/admin-guide/configuration/hierachical-caching.en.rst
b/doc/admin-guide/configuration/hierarchical-caching.en.rst
similarity index 100%
rename from doc/admin-guide/configuration/hierachical-caching.en.rst
rename to doc/admin-guide/configuration/hierarchical-caching.en.rst
diff --git a/doc/admin-guide/configuration/index.en.rst
b/doc/admin-guide/configuration/index.en.rst
index 1aecdbe..f9b2eca 100644
--- a/doc/admin-guide/configuration/index.en.rst
+++ b/doc/admin-guide/configuration/index.en.rst
@@ -31,5 +31,5 @@ Proxy Cache Configuration
explicit-forward-proxying.en
transparent-proxy.en
transparent-forward-proxying.en
- hierachical-caching.en
+ hierarchical-caching.en
proxy-protocol.en
diff --git a/doc/admin-guide/configuration/proxy-protocol.en.rst
b/doc/admin-guide/configuration/proxy-protocol.en.rst
index 2d7673b..c857de9 100644
--- a/doc/admin-guide/configuration/proxy-protocol.en.rst
+++ b/doc/admin-guide/configuration/proxy-protocol.en.rst
@@ -50,7 +50,7 @@ configured with
:ts:cv:`proxy.config.http.proxy_protocol_whitelist`.
.. important::
If the whitelist is configured, requests will only be accepted from
these
- IP addressses and must be prefaced with the PROXY v1 header.
+ IP addresses and must be prefaced with the PROXY v1 header.
See :ts:cv:`proxy.config.http.insert_forwarded` for configuration information.
Detection of the PROXY protocol header is automatic. If the PROXY header
@@ -81,7 +81,7 @@ Server would see the connection originating from |TS| at
``10.0.0.2``:
If the Load Balancer has the Proxy Protocol enabled, requests sent through the
Load Balancer will be preceded with the PROXY header. |TS| will detect the
PROXY header and transform that into the Forwarded: HTTP header if configured
to
-insert the Forwarded: header with the ``for`` paramter. In the example above,
+insert the Forwarded: header with the ``for`` parameter. In the example above,
if the client initiated a TLS connection, the Web Server can use the Forwarded:
header to determine the TLS connection originated from the client at
``192.168.1.100``:
diff --git a/doc/admin-guide/configuration/redirecting-http-requests.en.rst
b/doc/admin-guide/configuration/redirecting-http-requests.en.rst
index 8c69a9f..0bc8d8c 100644
--- a/doc/admin-guide/configuration/redirecting-http-requests.en.rst
+++ b/doc/admin-guide/configuration/redirecting-http-requests.en.rst
@@ -59,7 +59,7 @@ Offloading Heavily-Used Origin Servers
Traffic Server can accept requests on behalf of the origin server and improve
the speed and quality of web serving by reducing load and hot spots on
-backup origin servers. For example, a web hoster can maintain a scalable
+backup origin servers. For example, a web host can maintain a scalable
Traffic Server system with a set of low-cost, low-performance,
less-reliable PC origin servers as backup servers. In fact, a single
Traffic Server can act as the virtual origin server for multiple backup
diff --git a/doc/admin-guide/files/cache.config.en.rst
b/doc/admin-guide/files/cache.config.en.rst
index 3971b9a..4662992 100644
--- a/doc/admin-guide/files/cache.config.en.rst
+++ b/doc/admin-guide/files/cache.config.en.rst
@@ -158,7 +158,7 @@ specifiers of the rule in question.
Value Effect
=========================== ================================================
``never-cache`` Never cache specified objects, it will be
- overwrited by ``ttl-in-cache``.
+ overwritten by ``ttl-in-cache``.
``ignore-no-cache`` Ignore all ``Cache-Control: no-cache`` headers.
``ignore-client-no-cache`` Ignore ``Cache-Control: no-cache`` headers from
client requests.
@@ -255,7 +255,7 @@ ttl-in-cache and never-cache
----------------------------
When multiple rules are matched in the same request, ``never-cache`` will
always
-be overwrited by ``ttl-in-cache``. For example::
+be overwritten by ``ttl-in-cache``. For example::
# ttl-in-cache=1d never-cache=false
dest_domain=example.com action=never-cache
diff --git a/doc/admin-guide/files/ip_allow.config.en.rst
b/doc/admin-guide/files/ip_allow.config.en.rst
index ce7c632..8a43a72 100644
--- a/doc/admin-guide/files/ip_allow.config.en.rst
+++ b/doc/admin-guide/files/ip_allow.config.en.rst
@@ -44,7 +44,7 @@ address to which |TS| connects) is checked against the
specified IP address rang
Range specifications can be IPv4 or IPv6, but any single range must be one or
the other. Ranges can
be specified by two addresses, the lower address and the upper address,
separated by a dash, ``-``.
-Such a range inclusive and contains the lower, upper addresses and all
addresses inbetween. A range
+Such a range inclusive and contains the lower, upper addresses and all
addresses in between. A range
can also be specified by an address and a CIDR mask, separated by a slash,
``/``. This case is
converted to a range of the previous case by retaining only the left most
``mask`` bits, clearing
the rest for the lower address and setting them for the upper address. For
instance, a mask of
@@ -63,7 +63,7 @@ The ``action`` must be either ``ip_allow`` or ``ip_deny``.
This controls what |T
address is in the range and the method matches. If there is a match, |TS|
allows the connection (for
``ip_allow``) or denies it (``ip_deny``).
-For each inbound or outbound connection the applicable rule is selectd by
first match on the IP
+For each inbound or outbound connection the applicable rule is selected by
first match on the IP
address. The rule is then applied (if the method matches) or its opposite is
applied (if the method
doesn't match). If no rule is matched access is allowed. This makes each rule
both an accept and
deny, one explicit and the other implicit. The ``src_ip`` rules are checked
when a host connects
@@ -128,7 +128,7 @@ or::
dest_ip=10.0.0.0/16 action=ip_allow method=GET|HEAD
-This will match the IP address for the targer servers on the outbound
connection. Then, if the
+This will match the IP address for the target servers on the outbound
connection. Then, if the
method is ``GET`` or ``HEAD`` the connection will be allowed, otherwise the
connection will be
denied.
diff --git a/doc/admin-guide/files/parent.config.en.rst
b/doc/admin-guide/files/parent.config.en.rst
index 725b0d2..a1c3221 100644
--- a/doc/admin-guide/files/parent.config.en.rst
+++ b/doc/admin-guide/files/parent.config.en.rst
@@ -144,7 +144,7 @@ The following list shows the possible actions and their
allowed values.
If ``round_robin`` is set to ``consistent_hash``, you may add a ``unique
hash string``
following the ``weight`` for each parent. The ``hash string`` must start
with ``&``
and is used to build both the primary and secondary rings using the ``hash
string``
- for each parent insted of the parents ``hostname`` or ``ip address``. This
can be
+ for each parent instead of the parents ``hostname`` or ``ip address``.
This can be
useful so that two different hosts may be used to cache the same requests.
Example::
parent="p1.x.com:80|1.0&abcdef, p2.x.com:80|1.0&xyzl,
p3.x.com:80|1.0&ldffg" round_robin=consistent_hash
diff --git a/doc/admin-guide/files/records.config.en.rst
b/doc/admin-guide/files/records.config.en.rst
index b0d3c97..e6156a3 100644
--- a/doc/admin-guide/files/records.config.en.rst
+++ b/doc/admin-guide/files/records.config.en.rst
@@ -264,7 +264,7 @@ System Variables
:reloadable:
:units: seconds
- Specifies how often the output log is rolled, in seconds. The timer starts
on |TS| bootup.
+ Specifies how often the output log is rolled, in seconds. The timer starts
on |TS| startup.
.. ts:cv:: CONFIG proxy.config.output.logfile.rolling_size_mb INT 100
:reloadable:
@@ -794,7 +794,7 @@ mptcp
.. note::
- The ``Via`` transaction acode can be decoded with the `Via Decoder Ring
<http://trafficserver.apache.org/tools/via>`_.
+ The ``Via`` transaction code can be decoded with the `Via Decoder Ring
<http://trafficserver.apache.org/tools/via>`_.
.. ts:cv:: CONFIG proxy.config.http.response_via_str STRING
ApacheTrafficServer/${PACKAGE_VERSION}
:reloadable:
@@ -1768,7 +1768,7 @@ Proxy User Variables
information.
See :ts:cv:`proxy.config.http.server_ports` for information on how to
enable Proxy Protocol on a port.
- See :ref:`proxy-protocol` for more discussion on how |TS| tranforms the
`Forwarded: header`.
+ See :ref:`proxy-protocol` for more discussion on how |TS| transforms the
`Forwarded: header`.
.. ts:cv:: CONFIG proxy.config.http.normalize_ae INT 1
:reloadable:
@@ -1908,7 +1908,7 @@ Cache Control
option is combined with the cache key at cache lookup time.
Changing this value has the effect of an instantaneous, zero-cost
cache purge since it will cause all subsequent cache keys to
- change. Since this is an overrideable configuration, it can be
+ change. Since this is an overridable configuration, it can be
used to purge the entire cache, or just a specific :file:`remap.config`
rule.
@@ -2150,7 +2150,7 @@ Cache Control
.. ts:cv:: CONFIG proxy.config.cache.hit_evacuate_percent INT 0
The size of the region (as a percentage of the total content storage in a
:term:`cache stripe`) in front of the
- :term:`write cursor` that constitutes a recent access hit for evacutating
the accessed object.
+ :term:`write cursor` that constitutes a recent access hit for evacuating
the accessed object.
When an object is accessed it can be marked for evacuation, that is to be
copied over the write cursor and
thereby preserved from being overwritten. This is done if it is no more
than a specific number of bytes in front of
@@ -2379,7 +2379,7 @@ Customizable User Response Pages
:overridable:
A prefix for the file name to use to find an error template file. If set
(not the empty string)
- this value and an underscore are predended to the file name to find in the
template sets
+ this value and an underscore are prepended to the file name to find in the
template sets
directory. See :ref:`body-factory`.
.. ts:cv:: CONFIG proxy.config.body_factory.response_max_size INT 8192
@@ -2412,7 +2412,7 @@ Customizable User Response Pages
``3`` Enable all http UI endpoints.
===== ======================================================================
- To enable any enpoint there needs to be an entry in :file:`remap.config`
which
+ To enable any endpoint there needs to be an entry in :file:`remap.config`
which
specifically enables it. Such a line would look like: ::
map / http://{cache}
@@ -2721,7 +2721,7 @@ HostDB
Set the frequency (in seconds) to sync hostdb to disk. If set to zero
(default as of v9.0.0), we won't
sync to disk ever.
- Note: hostdb is syncd to disk on a per-partition basis (of which there are
64).
+ Note: hostdb is synced to disk on a per-partition basis (of which there are
64).
This means that the minimum time to sync all data to disk is
:ts:cv:`proxy.config.cache.hostdb.sync_frequency` * 64
Logging Configuration
@@ -2772,7 +2772,7 @@ Logging Configuration
:reloadable:
The tolerance for the log space limit (in megabytes). If the variable
:ts:cv:`proxy.config.log.auto_delete_rolled_files` is set to ``1``
- (enabled), then autodeletion of log files is triggered when the amount of
free space available in the logging directory is less than
+ (enabled), then auto-deletion of log files is triggered when the amount of
free space available in the logging directory is less than
the value specified here.
.. ts:cv:: CONFIG proxy.config.log.hostname STRING localhost
@@ -2908,7 +2908,7 @@ Diagnostic Logging Configuration
.. ts:cv:: CONFIG proxy.config.diags.output.alert STRING L
.. ts:cv:: CONFIG proxy.config.diags.output.emergency STRING SL
- The diagnosic output configuration variables control where Traffic
+ The diagnostic output configuration variables control where Traffic
Server should log diagnostic output. Messages at each diagnostic level
can be directed to any combination of diagnostic destinations.
Valid diagnostic message destinations are:
@@ -3008,7 +3008,7 @@ Diagnostic Logging Configuration
:reloadable:
:units: seconds
- Specifies how often the diagnostics log is rolled, in seconds. The timer
starts on |TS| bootup.
+ Specifies how often the diagnostics log is rolled, in seconds. The timer
starts on |TS| startup.
.. ts:cv:: CONFIG proxy.config.diags.logfile.rolling_size_mb INT 100
:reloadable:
@@ -3661,7 +3661,7 @@ SOCKS Processor
.. ts:cv:: CONFIG proxy.config.socks.socks_config_file STRING socks.config
- The socks_onfig file allows you to specify ranges of IP addresses
+ The socks.config file allows you to specify ranges of IP addresses
that will not be relayed to the SOCKS server. It can also be used
to configure AUTH information for SOCKSv5 servers.
@@ -3860,7 +3860,7 @@ Sockets
Changing this configuration can reduce CPU usage on an idle system, since
periodic tasks gets processed at these intervals. On busy servers, this
- overhead is diminished, since polled events triggers morefrequently.
+ overhead is diminished, since polled events triggers more frequently.
However, increasing the setting can also introduce additional latency for
certain operations, and timed events. It's recommended not to touch this
setting unless your CPU usage is unacceptable at idle workload. Some
diff --git a/doc/admin-guide/files/remap.config.en.rst
b/doc/admin-guide/files/remap.config.en.rst
index a37aaff..2956226 100644
--- a/doc/admin-guide/files/remap.config.en.rst
+++ b/doc/admin-guide/files/remap.config.en.rst
@@ -526,4 +526,4 @@ The file `two.example.com.config` contains::
.activatefilter allow_purge
map http://two.example.com http://origin-two.example.com
- .deactivatefilter dallowpurge
+ .deactivatefilter allow_purge
diff --git a/doc/admin-guide/files/ssl_server_name.yaml.en.rst
b/doc/admin-guide/files/ssl_server_name.yaml.en.rst
index 6f2f1a0..d146482 100644
--- a/doc/admin-guide/files/ssl_server_name.yaml.en.rst
+++ b/doc/admin-guide/files/ssl_server_name.yaml.en.rst
@@ -33,13 +33,13 @@ the items specified by this file and if there is a match,
the values specified i
the defaults. This is done during the inbound connection processing and be
some outbound properties
can be overridden again later, such as via :file:`remap.config` or plugins.
-By default this is named :file:`ssl_server_name.yaml`. The file can be changed
by settting
+By default this is named :file:`ssl_server_name.yaml`. The file can be changed
by setting
:ts:cv:`proxy.config.ssl.servername.filename`. This file is loaded on start up
and by
:option:`traffic_ctl config reload` if the file has been modified since
process start.
The configuration file is yaml-based. After parsing the configuration, a list
of tables will be the result.
Each table is a set of key / value pairs that create a configuration item.
This configuration file accepts
-wildcard entries. To apply an SNI based setting on all the servernames with a
common upper level domain name,
+wildcard entries. To apply an SNI based setting on all the server names with a
common upper level domain name,
the user needs to enter the fqdn in the configuration with a ``*.`` followed
by the common domain name. (``*.yahoo.com`` for e.g.,).
.. _override-verify-origin-server:
@@ -74,7 +74,7 @@ verify_client One of the values :code:`NONE`,
:code:`MODERATE`, or :
By default this is
:ts:cv:`proxy.config.ssl.client.certification_level`.
valid_tls_versions_in This specifies the list of TLS protocols that will
be offered to user agents during
- the TLS negotiaton. This replaces the global
settings in :ts:cv:`proxy.config.ssl.TLSv1`,
+ the TLS negotiation. This replaces the global
settings in :ts:cv:`proxy.config.ssl.TLSv1`,
:ts:cv:`proxy.config.ssl.TLSv1_1`,
:ts:cv:`proxy.config.ssl.TLSv1_2`,
and :ts:cv:`proxy.config.ssl.TLSv1_3`. The potential
values are TLSv1, TLSv1_1, TLSv1_2, and
TLSv1_3. You must list all protocols that |TS|
should offer to the client when using
@@ -117,7 +117,7 @@ forward_route Destination as an FQDN and port,
separated by a colon
need to be HTTP.
=========================
==============================================================================
-Client verification, via ``verify_client``, correponds to setting
+Client verification, via ``verify_client``, corresponds to setting
:ts:cv:`proxy.config.ssl.client.certification_level` for this connection as
noted below.
:code:`NONE` -- ``0``
@@ -176,7 +176,7 @@ Disable HTTP/2 for ``no-http2.example.com``.
- fqdn: no-http2.example.com
disable_h2: true
-Require client certificate verification for ``example.com`` and any server
name ending with ``.yahoo.com``. Therefore, client request for a server name
ending with yahoo.com (for e.g., def.yahoo.com, abc.yahoo.com etc.) will cause
|TS| require and verify the client certificate. By contrast, |TS| will allow a
client certficate to be provided for ``example.com`` and if it is, |TS| will
require the certificate to be valid.
+Require client certificate verification for ``example.com`` and any server
name ending with ``.yahoo.com``. Therefore, client request for a server name
ending with yahoo.com (for e.g., def.yahoo.com, abc.yahoo.com etc.) will cause
|TS| require and verify the client certificate. By contrast, |TS| will allow a
client certificate to be provided for ``example.com`` and if it is, |TS| will
require the certificate to be valid.
.. code-block:: yaml
diff --git a/doc/admin-guide/files/storage.config.en.rst
b/doc/admin-guide/files/storage.config.en.rst
index 1945dc0..192bcf2 100644
--- a/doc/admin-guide/files/storage.config.en.rst
+++ b/doc/admin-guide/files/storage.config.en.rst
@@ -139,7 +139,7 @@ Linux Example
modern Linux supports `alternative symlinked names for disk devices
<https://wiki.archlinux.org/index.php/persistent_block_device_naming#by-id_and_by-path>`_
in the ``/dev/disk``
directory structure. As noted for the :ref:`assignment-table` the path
used for the disk can effect
- the cache if it changes. This can be ameloriated in some cases by using
one of the alternate paths
+ the cache if it changes. This can be ameliorated in some cases by using
one of the alternate paths
in via ``/dev/disk``. Note that if the ``by-id`` or ``by-path`` style is
used, replacing a failed drive will cause
that path to change because the new drive will have a different physical
ID or path. The original hash string can
be kept by adding :arg:`id` or :arg:`path` with the original path to the
storage line.
diff --git a/doc/admin-guide/installation/index.en.rst
b/doc/admin-guide/installation/index.en.rst
index 07caf4c..fed6f8a 100644
--- a/doc/admin-guide/installation/index.en.rst
+++ b/doc/admin-guide/installation/index.en.rst
@@ -131,7 +131,7 @@ Layouts
Preparing the Source Tree
-------------------------
-If you are buiding from a checkout of the Git repository, you will need to
+If you are building from a checkout of the Git repository, you will need to
prepare the source tree by regenerating the configuration scripts. This is
performed by running::
diff --git a/doc/admin-guide/layer-4-routing.en.rst
b/doc/admin-guide/layer-4-routing.en.rst
index 2355ecd..5501a4c 100644
--- a/doc/admin-guide/layer-4-routing.en.rst
+++ b/doc/admin-guide/layer-4-routing.en.rst
@@ -31,7 +31,7 @@ data read on one connection to the other and vice versa.
.. figure:: ../uml/images/l4-basic-sequence.svg
:align: center
-In this way it acts similary to `nc <https://linux.die.net/man/1/nc>`__.
+In this way it acts similarly to `nc <https://linux.die.net/man/1/nc>`__.
The primary differences between different types of layer 4 routing is the
mechanism by which |TS|
creates the outbound connection. This is described in detail in the type
specific documentation.
@@ -125,5 +125,5 @@ In this case the proxy request is available in the
:c:macro:`TS_HTTP_TXN_START_H
cannot be done using remap because for a ``CONNECT`` there is no remap phase.
Note that for a
tunneled connection like this, the only transaction hooks that will be
triggered are
:c:macro:`TS_HTTP_TXN_START_HOOK` and :c:macro:`TS_HTTP_TXN_CLOSE_HOOK`. In
addition, because |TS|
-does not terminate (and thefore does not decrypt) the connection, it cannot be
cached or served from
+does not terminate (and therefore does not decrypt) the connection, it cannot
be cached or served from
cache.
diff --git a/doc/admin-guide/logging/formatting.en.rst
b/doc/admin-guide/logging/formatting.en.rst
index bb5ccb7..e909f42 100644
--- a/doc/admin-guide/logging/formatting.en.rst
+++ b/doc/admin-guide/logging/formatting.en.rst
@@ -348,7 +348,7 @@ The output generated by these fields has the pattern::
(The size of some messages may exceed internal buffer capacity. This may
result in the value of the last header being truncated, in which case, the
-value will end with ``...}``. This may also result in the ommission of
+value will end with ``...}``. This may also result in the omission of
entire tag/value pairs.)
.. _admin-logging-fields-methods:
@@ -692,7 +692,7 @@ Field Source Description
cqtd Client Request Client request timestamp. Specifies the date of
the client request in the format ``YYYY-MM-DD``
(four digit year, two digit month, two digit day
- - with leading zeroes as necessary for the latter
+ - with leading zeros as necessary for the latter
two).
cqtn Client Request Client request timestamp in the Netscape
timestamp format.
@@ -705,7 +705,7 @@ cqts Client Request Same as cqtq_, but as an
integer without
cqth Client Request Same as cqts_, but represented in hexadecimal.
cqtt Client Request Client request timestamp in the 24-hour format
``hh:mm:ss`` (two digit hour, minutes, and
- seconds - with leading zeroes as necessary).
+ seconds - with leading zeros as necessary).
crat Origin Response Retry-After time in seconds if specified in the
origin server response.
ms Proxy Timestamp in milliseconds of a specific milestone
diff --git a/doc/admin-guide/logging/understanding.en.rst
b/doc/admin-guide/logging/understanding.en.rst
index 56432fa..c6d70b8 100644
--- a/doc/admin-guide/logging/understanding.en.rst
+++ b/doc/admin-guide/logging/understanding.en.rst
@@ -137,7 +137,7 @@ Function Description
within the interval. May be used with any type of field; numeric or
otherwise.
``LAST`` The value of the last event, chronologically, which was observed
- within the interval. May be used with any type of field; nuemric or
+ within the interval. May be used with any type of field; numeric or
otherwise.
``SUM`` Sum of the given field's value from all events within the interval.
May only be used on numeric fields.
diff --git a/doc/admin-guide/monitoring/statistics/accessing.en.rst
b/doc/admin-guide/monitoring/statistics/accessing.en.rst
index b22cf3f..341b45e 100644
--- a/doc/admin-guide/monitoring/statistics/accessing.en.rst
+++ b/doc/admin-guide/monitoring/statistics/accessing.en.rst
@@ -55,7 +55,7 @@ Stats Over HTTP
===============
|TS| includes a stable plugin, :ref:`admin-plugins-stats-over-http`, which
provides
-HTTP access to all |TS| statistcs. The plugin returns a JSON object with all
+HTTP access to all |TS| statistics. The plugin returns a JSON object with all
statistics and their current values. It is not possible to return a subset of
the statistics. The plugin must be enabled before you may use it.
diff --git a/doc/admin-guide/performance/index.en.rst
b/doc/admin-guide/performance/index.en.rst
index acd5c3d..ed3d718 100644
--- a/doc/admin-guide/performance/index.en.rst
+++ b/doc/admin-guide/performance/index.en.rst
@@ -111,7 +111,7 @@ megabytes of RAM cache for every gigabyte of disk cache
storage, though this
setting can be adjusted manually in :file:`records.config` using the setting
:ts:cv:`proxy.config.cache.ram_cache.size`. |TS| will, under the default
configuration, adjust this automatically if your system does not have enough
-physical memory to accomodate the aforementioned target.
+physical memory to accommodate the aforementioned target.
Aside from the cost of physical memory, and necessary supporting hardware to
make use of large amounts of RAM, there is little downside to increasing the
@@ -234,7 +234,7 @@ your cache, leaving the default at a minute or two, but
enforce a much stricter
timeout on a set of very small, incredibly heavily accessed objects for which
you can construct a ``map`` rule with the goal of reducing the chances that a
few bad actors (misconfigured or misbehaving clients) may generate too much
-connection pressure on your cache. The tradeoff may be that some perfectly
+connection pressure on your cache. The trade off may be that some perfectly
innocent, but slow clients may have their connections terminated early. As with
all performance tuning efforts, your needs are likely to vary from others' and
should be carefully considered and closely monitored.
@@ -276,7 +276,7 @@ When :ref:`background fills
<admin-config-read-while-writer>` are enabled,
time after which |TS| will abort the fill attempt and close the origin
server connection that was being used. Setting this to zero disables the
timeout, but modifying the value and enforcing a timeout may help in
-situtations where your origin servers stall connections without closing.
+situations where your origin servers stall connections without closing.
::
@@ -433,7 +433,7 @@ globally, especially if your cache contains objects of
varying sizes and deals
with clients which may support a range of speeds (and therefore take less or
more time to complete normal, healthy data exchanges). However, there may be
configurations in which small objects need to be exchanged in very short
-periods and you wish your |TS| cache to enforce these time resrictions by
+periods and you wish your |TS| cache to enforce these time restrictions by
closing connections which exceed them.
The variables :ts:cv:`proxy.config.http.transaction_no_activity_timeout_in` and
@@ -487,7 +487,7 @@ Network Tuning
:ts:cv:`proxy.config.net.connections_throttle`
-Error responses from origins are conistent and costly
+Error responses from origins are consistent and costly
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If error responses are costly for your origin server to generate, you may elect
@@ -535,6 +535,6 @@ shortcuts to identifying problem areas, or realizing easier
performance gains.
.. TODO::
- - origins not sending proper expiration headers (can fix at the origin
(preferable) or use proxy.config.http.cache.heuristic_(min|max)_lifetime as
hacky bandaids)
+ - origins not sending proper expiration headers (can fix at the origin
(preferable) or use proxy.config.http.cache.heuristic_(min|max)_lifetime as
hacky band-aids)
- cookies and http_auth prevent caching
- avoid thundering herd with read-while-writer (link to section in
http-proxy-caching)
diff --git a/doc/admin-guide/plugins/access_control.en.rst
b/doc/admin-guide/plugins/access_control.en.rst
index c7b9a3e..7fcf7e5 100644
--- a/doc/admin-guide/plugins/access_control.en.rst
+++ b/doc/admin-guide/plugins/access_control.en.rst
@@ -112,7 +112,7 @@ Let us say CDN_'s domain name is ``example-cdn.com`` and
origin_'s domain name i
alt config:use_redirect=//true//
CDN -> Origin : HEAD https://example.com/path/object
activate Origin
- else config:use_returect=//false//
+ else config:use_redirect=//false//
CDN -> Origin : GET https://example.com/path/object
deactivate CDN
end
@@ -193,7 +193,7 @@ This use case is similar to `use case 1`_ but makes sure
all (cacheable) request
**<14>** When the origin_ responds with a valid access token in
``TokenRespHdr`` the CDN_ sets the ``TokenCookie`` by using a ``302 Redirect``
response with a ``Location`` header containing the URI of original UA_ request.
-In this way the after the initial failure the UA_ request is repeated with a
valid access token and can be safely cached in the CDN_ cache (if the object is
catchable)
+In this way the after the initial failure the UA_ request is repeated with a
valid access token and can be safely cached in the CDN_ cache (if the object is
cacheable)
The support of this use case is still not implemented.
@@ -321,7 +321,7 @@ Plugin configuration
* Extract information into a request header
* ``--extract-subject-to-header=<header_name>`` (`optional`,
default:empty/unused) - extract the access token `subject` claim into a request
header with ``<header_name>`` for debugging purposes and logging or to be able
to modify the cache key by using :ref:`admin-plugins-cachekey` plugin.
* ``--extract-tokenid-to-header=<header_name>`` (`optional`,
default:empty/unused) - extract the access token `token id` claim into a
request header with ``<header_name>`` for debugging purposes and logging
- * ``--extract-status-to-header=<header_name>`` (`optional`,
default:empty/unused) - extract the access token validation statusa request
header with ``<header_name>`` for debugging purposes and logging
+ * ``--extract-status-to-header=<header_name>`` (`optional`,
default:empty/unused) - extract the access token validation status request
header with ``<header_name>`` for debugging purposes and logging
* Plugin setup related
diff --git a/doc/admin-guide/plugins/buffer_upload.en.rst
b/doc/admin-guide/plugins/buffer_upload.en.rst
index 7cb8140..6f22d80 100644
--- a/doc/admin-guide/plugins/buffer_upload.en.rst
+++ b/doc/admin-guide/plugins/buffer_upload.en.rst
@@ -33,7 +33,7 @@ Memory buffering (buffer the entire POST data in IOBuffer
before connecting to O
==================================================================================
Memory buffer size is configured with "mem_buffer_size" in config file.
Default and minimum value is 32K. You can
-increase it in the config file. If the size of a request is larger than the
"mem_buffer_size" value specifiied in the
+increase it in the config file. If the size of a request is larger than the
"mem_buffer_size" value specified in the
config file, then the upload proxy feature will be disabled for this
particular request
Disk buffering (buffer the entire POST data on disk before connecting to OS)
@@ -63,7 +63,7 @@ Other Features
1. Default buffering mode is disk aio buffering mode. To turn off disk
buffering, add a "use_disk_buffer 0" line in
config file
-2. All request headers inlcuding cookies plus the entire POST data will be
buffered (either in memory or on disk)
+2. All request headers including cookies plus the entire POST data will be
buffered (either in memory or on disk)
Configuration File
==================
diff --git a/doc/admin-guide/plugins/cachekey.en.rst
b/doc/admin-guide/plugins/cachekey.en.rst
index 701cfad..5342d8b 100644
--- a/doc/admin-guide/plugins/cachekey.en.rst
+++ b/doc/admin-guide/plugins/cachekey.en.rst
@@ -59,7 +59,7 @@ Cache key structure and related plugin parameters
│ (default) | (optional) │ (optional) │ (optional) │ (default) │
(default) │
└─────────────┴──────────────┴──────────────┴──────────────┴─────────────┴─────────────┘
-* The cache key set by the cachekey plugin can be considered as devided into
several sections.
+* The cache key set by the cachekey plugin can be considered as divided into
several sections.
* Every section is manipulated separately by the related plugin parameters
(more info in each section description below).
* "User-Agent", "Headers" and "Cookies" sections are optional and will be
missing from the cache key if no related plugin parameters are used.
* "Prefix", "Path" and "Query" sections always have default values even if no
related plugin parameters are used.
@@ -81,7 +81,7 @@ Cache key structure and related plugin parameters
* ``--capture-prefix=<capture_definition>`` (default: empty string) - if
specified and not empty then strings are captured from ``host:port`` based on
the ``<capture_definition>`` and are added to the cache key.
* ``--capture-prefix-uri=<capture_definition>`` (default: empty string) - if
specified and not empty then strings are captured from the entire URI based on
the ``<capture_definition>`` and are added to the cache key.
* If any of the "Prefix" related plugin parameters are used together in the
plugin configuration they are added to the cache key in the order shown in the
diagram.
-* ``--remove-prefix=<true|false|yes|no|0|1`` (default: false) - if specified
the prefix elements (host, port) are not processed nor appended to the
cachekey. All prefix related plugin paramenters are ignored if this parameter
is ``true``, ``yes`` or ``1``.
+* ``--remove-prefix=<true|false|yes|no|0|1`` (default: false) - if specified
the prefix elements (host, port) are not processed nor appended to the
cachekey. All prefix related plugin parameters are ignored if this parameter is
``true``, ``yes`` or ``1``.
@@ -150,7 +150,7 @@ Cache key structure and related plugin parameters
* if no path related plugin parameters are used, the URI path string is
included in the cache key.
* ``--capture-path=<capture_definition>`` (default: empty string) - if
specified and not empty then strings are captured from URI path based on the
``<capture_definition>`` and are added to the cache key.
* ``--capture-path-uri=<capture_definition>`` (default: empty string) - if
specified and not empty then strings are captured from the entire URI based on
the ``<capture_definition>`` and are added to the cache key.
-* ``--remove-path=<true|false|yes|no|0|1`` (default: false) - if specified the
HTTP URI path element is not processed nor appended to the cachekey. All path
related plugin paramenters are ignored if this parameter is ``true``, ``yes``
or ``1``.
+* ``--remove-path=<true|false|yes|no|0|1`` (default: false) - if specified the
HTTP URI path element is not processed nor appended to the cachekey. All path
related plugin parameters are ignored if this parameter is ``true``, ``yes`` or
``1``.
"Query" section
^^^^^^^^^^^^^^^
@@ -216,7 +216,7 @@ Because of the ATS core (remap) and the CacheKey plugin
implementation there is
* The per-remap instance uses the URI **during** remap (after
``TS_HTTP_PRE_REMAP_HOOK`` and before ``TS_HTTP_POST_REMAP_HOOK``) which leads
to a different URI to be used depending on plugin order in the remap rule.
* If CacheKey plugin is the first plugin in the remap rule the URI used
will be practically the same as the pristine URI.
- * If the CacheKey plugin is the last plugin in the remap rule (which is
right before ``TS_HTTP_POST_REMAP_HOOK``) the behavior will be simillar to the
global instnance.
+ * If the CacheKey plugin is the last plugin in the remap rule (which is
right before ``TS_HTTP_POST_REMAP_HOOK``) the behavior will be similar to the
global instance.
Detailed examples and troubleshooting
@@ -580,7 +580,7 @@ then ``browser`` will be used when constructing the key.
Cacheurl plugin to cachekey plugin migration
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The plugin `cachekey` was not meant to replace the cacheurl plugin in terms of
having exactly the same cache key strings generated. It just allows the
operator to exctract elements from the HTTP URI in the same way the `cacheurl`
does (through a regular expression, please see `<capture_definition>` above).
+The plugin `cachekey` was not meant to replace the cacheurl plugin in terms of
having exactly the same cache key strings generated. It just allows the
operator to extract elements from the HTTP URI in the same way the `cacheurl`
does (through a regular expression, please see `<capture_definition>` above).
The following examples demonstrate different ways to achieve `cacheurl`
compatibility on a cache key string level in order to avoid invalidation of the
cache.
@@ -589,7 +589,7 @@ The operator could use `--capture-path-uri`,
`--capture-path`, `--capture-prefix
By using `--separator=<string>` the operator could override the default
separator to an empty string `--separator=` and thus make sure there are no
cache key element separators.
-Example 1: Let us say we have a capture definition used in `cacheurl`. Now by
using `--capture-prefix-uri` one could extract elements through the same
caplture definition used with `cacheurl`, remove the cache key element
separator `--separator=` and by using `--capture-path-uri` could remove the URI
path and by using `--remove-all-params=true` could remove the query string::
+Example 1: Let us say we have a capture definition used in `cacheurl`. Now by
using `--capture-prefix-uri` one could extract elements through the same
capture definition used with `cacheurl`, remove the cache key element separator
`--separator=` and by using `--capture-path-uri` could remove the URI path and
by using `--remove-all-params=true` could remove the query string::
@plugin=cachekey.so \
@pparam=--capture-prefix-uri=/.*/$0/ \
@@ -613,7 +613,7 @@ Example 3: Same result as the above but this time by using
`--capture-path-uri`
@pparam=--remove-all-params=true \
@pparam=--separator=
-Example 4: Let us say that we would like to capture from URI in similar to
`cacheurl` way but also sort the query parameters (which is not supported by
`cacheurl`). We could achieve that by using `--capture-prefix-uri` to capture
by using a caplture definition to process the URI before `?` and using
`--remove-path` to remove the URI path and `--sort-params=true` to sort the
query parameters::
+Example 4: Let us say that we would like to capture from URI in similar to
`cacheurl` way but also sort the query parameters (which is not supported by
`cacheurl`). We could achieve that by using `--capture-prefix-uri` to capture
by using a capture definition to process the URI before `?` and using
`--remove-path` to remove the URI path and `--sort-params=true` to sort the
query parameters::
@plugin=cachekey.so \
@pparam=--capture-prefix-uri=/([^?]*)/$1/ \
diff --git a/doc/admin-guide/plugins/certifier.en.rst
b/doc/admin-guide/plugins/certifier.en.rst
index c946b88..4d6bb55 100644
--- a/doc/admin-guide/plugins/certifier.en.rst
+++ b/doc/admin-guide/plugins/certifier.en.rst
@@ -51,7 +51,7 @@ Plugin Configuration
* Specify certificate generation related files. If any of the following
parameters is missing, the dynamic generation will be disabled.
.. option:: --sign-cert <path_to_certificate>
- (`optional`, default:empty/unused) - specifies the path to the root CA
certficate. In most cases, this would be a self-signed certificate that is
configured to be trusted by all potential clients. Path should be the path and
file name of the cert. If it is relative, it is relative to the Traffic Server
configuration directory.
+ (`optional`, default:empty/unused) - specifies the path to the root CA
certificate. In most cases, this would be a self-signed certificate that is
configured to be trusted by all potential clients. Path should be the path and
file name of the cert. If it is relative, it is relative to the Traffic Server
configuration directory.
.. option:: --sign-key <path_to_key>
diff --git a/doc/admin-guide/plugins/compress.en.rst
b/doc/admin-guide/plugins/compress.en.rst
index 7e20f7c..86c8060 100644
--- a/doc/admin-guide/plugins/compress.en.rst
+++ b/doc/admin-guide/plugins/compress.en.rst
@@ -115,7 +115,7 @@ Provides a wildcard pattern which will be applied to
request URLs. Any which
match the pattern will be considered compressible, and only deflated versions
of the objects will be cached and returned to clients. This may be useful for
objects which already have their own compression built-in, to avoid the expense
-of multiple rounds of compression for trivial gains. If the regex is preceeded
by
+of multiple rounds of compression for trivial gains. If the regex is preceded
by
``!`` (for example ``allow !*/nothere/*``), it disables the plugin from those
machine URLs.
enabled
diff --git a/doc/admin-guide/plugins/escalate.en.rst
b/doc/admin-guide/plugins/escalate.en.rst
index af0c2a2..56ec1fd 100644
--- a/doc/admin-guide/plugins/escalate.en.rst
+++ b/doc/admin-guide/plugins/escalate.en.rst
@@ -31,7 +31,7 @@ Plugin Configuration
--------------------
The escalate plugin is a remap plugin (not global) and takes a parameter
-with two delimitated fields:
``comma-separated-error-codes:secondary-origin-server``. For instance,
+with two delimited fields:
``comma-separated-error-codes:secondary-origin-server``. For instance,
``@pparam=401,404,410,502:second-origin.example.com``
diff --git a/doc/admin-guide/plugins/esi.en.rst
b/doc/admin-guide/plugins/esi.en.rst
index 1bbb916..0a8b521 100644
--- a/doc/admin-guide/plugins/esi.en.rst
+++ b/doc/admin-guide/plugins/esi.en.rst
@@ -26,7 +26,7 @@ This plugin implements the ESI specification.
Specification
=============
-Supportted ESI tags:
+Supported ESI tags:
::
@@ -152,7 +152,7 @@ Useful Note
1. You can provide proper cache control header and the ESI response and ESI
include response can be cached separately.
It is extremely useful for rendering page with multiple modules. The page
layout can be a ESI response with multiple
- ESI include include, each for different module. The page layour ESI
response can be cached and each individual ESI
+ ESI include include, each for different module. The page layout ESI
response can be cached and each individual ESI
include can also be cached with different duration.
2. You should run the plugin without using "packed node support" because it is
not fully tested.
diff --git a/doc/admin-guide/plugins/fq_pacing.en.rst
b/doc/admin-guide/plugins/fq_pacing.en.rst
index 1ea2a1f..fcc7376 100644
--- a/doc/admin-guide/plugins/fq_pacing.en.rst
+++ b/doc/admin-guide/plugins/fq_pacing.en.rst
@@ -38,7 +38,7 @@ First, enable the FQ qdisc by setting
``net.core.default_qdisc=fq`` in ``/etc/sy
The `FQ Pacing` plugin is a :term:`remap plugin`. Enable it by adding
``fq_pacing.so`` to your :file:`remap.config` file. Provide a
``--rate=BytesPerSec`` option to set
-the maxmimum rate of a TCP connection matching that remap line.
+the maximum rate of a TCP connection matching that remap line.
Here is an example remap.config entry:
diff --git a/doc/admin-guide/plugins/header_rewrite.en.rst
b/doc/admin-guide/plugins/header_rewrite.en.rst
index 63df29f..05267b5 100644
--- a/doc/admin-guide/plugins/header_rewrite.en.rst
+++ b/doc/admin-guide/plugins/header_rewrite.en.rst
@@ -819,7 +819,7 @@ Note: In versions prior to ATS v9.0.0, an alternative
string expansion was avail
expansions are no longer available, but the following table can help
migrations:
========================
==========================================================================
-Old expansion variable Condition variable to use with concatenatinos
+Old expansion variable Condition variable to use with concatenations
========================
==========================================================================
%<proto> %{CLIENT-URL:SCHEME}
%<port> %{CLIENT-URL:PORT}
diff --git a/doc/admin-guide/plugins/hook-trace.en.rst
b/doc/admin-guide/plugins/hook-trace.en.rst
index 9d1a1b0..56ce7c3 100644
--- a/doc/admin-guide/plugins/hook-trace.en.rst
+++ b/doc/admin-guide/plugins/hook-trace.en.rst
@@ -30,7 +30,7 @@ The plugin begins by adding a global hook on each of the
hooks it
is interested in. Next, in the event handler, we simply cast the
event data pointer to the expected type.
-Hook events can be shown in the |TS| diagnosic log by using the
+Hook events can be shown in the |TS| diagnostic log by using the
``hook-trace`` diagnostic tag::
$ traffic_server -T hook-trace
diff --git a/doc/admin-guide/plugins/lua.en.rst
b/doc/admin-guide/plugins/lua.en.rst
index dd890e3..93b443a 100644
--- a/doc/admin-guide/plugins/lua.en.rst
+++ b/doc/admin-guide/plugins/lua.en.rst
@@ -2202,7 +2202,7 @@ ts.http.resp_transform.get_upstream_bytes
**context:** transform handler
-**description**: This function can be used to retrive the total bytes to be
received from the upstream. If we got
+**description**: This function can be used to retrieve the total bytes to be
received from the upstream. If we got
chunked response body from origin server, TS_LUA_INT64_MAX will be returned.
Here is an example:
@@ -2243,7 +2243,7 @@ ts.http.resp_transform.get_upstream_watermark_bytes
**context:** transform handler
-**description**: This function can be used to retrive the current watermark
bytes for the upstream transform buffer.
+**description**: This function can be used to retrieve the current watermark
bytes for the upstream transform buffer.
`TOP <#lua-plugin>`_
@@ -2344,7 +2344,7 @@ ts.http.is_websocket
**context:** do_remap/do_os_response or do_global_* or later
-**description:** This function can be used to tell if the transacton is
websocket
+**description:** This function can be used to tell if the transaction is
websocket
Here is an example:
@@ -2833,7 +2833,7 @@ ts.fetch
**description:** Issues a synchronous but still non-block http request with
the ``url`` and the optional ``table``.
-Returns a Lua table with serveral slots (res.status, res.header, res.body, and
res.truncated).
+Returns a Lua table with several slots (res.status, res.header, res.body, and
res.truncated).
``res.status`` holds the response status code.
@@ -2864,7 +2864,7 @@ Here is a basic example:
ts.hook(TS_LUA_HOOK_POST_REMAP, post_remap)
end
-We can set the optional table with serveral members:
+We can set the optional table with several members:
``header`` holds the request header table.
@@ -3516,7 +3516,7 @@ ts.http.enable_redirect
**context:** do_remap/do_os_response or do_global_* or later.
-**decription:** This function can be used to make transaction follow redirect
+**description:** This function can be used to make transaction follow redirect
Here is an example:
@@ -3536,7 +3536,7 @@ ts.http.set_debug
**context:** do_remap/do_os_response or do_global_* or later.
-**decription:** This function can be used to enable debug log for the
transaction
+**description:** This function can be used to enable debug log for the
transaction
Here is an example:
@@ -3556,7 +3556,7 @@ ts.http.cntl_get
**context:** do_remap/do_os_response or do_global_* or later.
-**description:** This function can be used to retireve the value of control
channel.
+**description:** This function can be used to retrieve the value of control
channel.
::
@@ -3605,7 +3605,7 @@ ts.http.milestone_get
**context:** do_remap/do_os_response or do_global_* or later.
-**description:** This function can be used to retireve the various milestone
times. They are how long the
+**description:** This function can be used to retrieve the various milestone
times. They are how long the
transaction took to traverse portions of the HTTP state machine. Each
milestone value is a fractional number
of seconds since the beginning of the transaction.
diff --git a/doc/admin-guide/plugins/metalink.en.rst
b/doc/admin-guide/plugins/metalink.en.rst
index e6a028a..921924f 100644
--- a/doc/admin-guide/plugins/metalink.en.rst
+++ b/doc/admin-guide/plugins/metalink.en.rst
@@ -51,7 +51,7 @@ header and a :mailheader:`Digest: SHA-256=...` header, it
checks if
the URL in the :mailheader:`Location` header is already cached. If it
isn't, then it tries to find a URL that is cached to use instead. It
looks in the cache for some object that matches the digest in the
-:mailheader:`Digest` header and if it succeeds, then it rewites the
+:mailheader:`Digest` header and if it succeeds, then it rewrites the
:mailheader:`Location` header with that object's URL.
This way a client should get sent to a URL that's already cached and
diff --git a/doc/admin-guide/plugins/money_trace.en.rst
b/doc/admin-guide/plugins/money_trace.en.rst
index c507eb9..41d7406 100644
--- a/doc/admin-guide/plugins/money_trace.en.rst
+++ b/doc/admin-guide/plugins/money_trace.en.rst
@@ -20,7 +20,7 @@
Money Trace Plugin
==================
-This is a remap plugin that allows ATS to participate in a distrbuted tracing
system based upon
+This is a remap plugin that allows ATS to participate in a distributed
tracing system based upon
the Comcast "Money" distributed tracing and monitoring library. The Comcast
"Money" library has
its roots in Google's Dapper and Twitters Zipkin systems. A money trace
header or session id, is
attached to transaction and allows an operator with the appropriate logging
systems in place,
diff --git a/doc/admin-guide/plugins/prefetch.en.rst
b/doc/admin-guide/plugins/prefetch.en.rst
index 9b3b8c6..b958392 100644
--- a/doc/admin-guide/plugins/prefetch.en.rst
+++ b/doc/admin-guide/plugins/prefetch.en.rst
@@ -112,7 +112,7 @@ request, it will either find it in cache or begin the fetch
from its next tier.
Since the request from the child has the special header, the parent will only
send the headers of the object back to the client, saving network and
processing
bytes. The child thus does not cache the pre-fetched object which is ok since
-the user may not hit that same child for the subsquent object.
+the user may not hit that same child for the subsequent object.
Then, when the user makes their next request for the pre-fetched object, the
child that handles the request will perform the consistent-hash, find the
@@ -186,12 +186,12 @@ attempts to minimize the extraneous resources used.
Minimizing **next object** prefetch overhead
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The current implementation relies on the following assumptions and egnineering
+The current implementation relies on the following assumptions and engineering
compromises:
* **First match the next object pattern** defined by ``--fetch-path-pattern``
plugin parameter, not matching requests are ignored (prefetch is never
triggered)
-* **Define a prefetch policy** which tries to suppress uneccessary **next
object**
+* **Define a prefetch policy** which tries to suppress unnecessary **next
object**
prefetches for the most recently used requests which are assumed should be
already
in cache. Currently only ``lru:n`` policy is supported, it is using an
URI-hash LRU
cache which evicts the least recently used elements first. Every request's
**cache key**
@@ -250,7 +250,7 @@ The plugin maintains the following metrics:
* Prefetch request status related
* ``fetch.active`` - number of currently active prefetch requests (counter)
- * ``fetch.completed``- number of succesfully completed prefetch requests
(counter)
+ * ``fetch.completed``- number of successfully completed prefetch requests
(counter)
* ``fetch.errors`` - number of failed prefetch requests (counter)
* ``fetch.timeouts`` - number of timed-out prefetch requests (counter)
* ``fetch.throttled`` - number of throttled prefetch requests (counter),
throttle limit defined by ``--fetch-max``
diff --git a/doc/admin-guide/plugins/regex_remap.en.rst
b/doc/admin-guide/plugins/regex_remap.en.rst
index ead5456..312a608 100644
--- a/doc/admin-guide/plugins/regex_remap.en.rst
+++ b/doc/admin-guide/plugins/regex_remap.en.rst
@@ -143,7 +143,7 @@ remap.config. The following options are available ::
This can be useful to force a particular response for some URLs, e.g. ::
- ^/(ogre.*)/bad http://www.examle.com/ @status=404
+ ^/(ogre.*)/bad http://www.example.com/ @status=404
Or, to force a 302 redirect ::
diff --git a/doc/admin-guide/plugins/regex_revalidate.en.rst
b/doc/admin-guide/plugins/regex_revalidate.en.rst
index a24fbee..18a5823 100644
--- a/doc/admin-guide/plugins/regex_revalidate.en.rst
+++ b/doc/admin-guide/plugins/regex_revalidate.en.rst
@@ -32,7 +32,7 @@ Purpose
This plugin's intended use is the selective forcing of revalidations on cache
objects which are not yet marked as stale in |TS| but which may have been
updated at the origin - without needing to alter cache control headers,
-pre-emptively purge the object from the cache manually, or adjust the global
+preemptively purge the object from the cache manually, or adjust the global
cache revalidation settings (such as fuzz times) used by other plugins.
Forced cache revalidations may be as specifically or loosely targeted as a
diff --git a/doc/admin-guide/plugins/s3_auth.en.rst
b/doc/admin-guide/plugins/s3_auth.en.rst
index 82625eb..87f1a92 100644
--- a/doc/admin-guide/plugins/s3_auth.en.rst
+++ b/doc/admin-guide/plugins/s3_auth.en.rst
@@ -117,7 +117,7 @@ According to `Transferring Payload in a Single Chunk
<http://docs.aws.amazon.com
the ``CanonicalHeaders`` list *must* include the ``Host`` header, the
``Content-Type`` header if present in the request and all the ``x-amz-*``
headers
so ``--v4-include-headers`` and ``--v4-exclude-headers`` do not impact those
headers and they are *always* signed.
-The ``Via`` and ``X-Forwarded-For`` headers are *always* excluded from the
signature since they are meant to be changed by the proxies and signing them
could lead to invalidation of the signatue.
+The ``Via`` and ``X-Forwarded-For`` headers are *always* excluded from the
signature since they are meant to be changed by the proxies and signing them
could lead to invalidation of the signature.
If ``--v4-include-headers`` is not specified all headers except those
specified in ``--v4-exclude-headers`` will be signed.
@@ -138,7 +138,7 @@ There are 4 plugin configuration options for version 2::
--config <config file>
--version=2
-This is a pretty barebone start for the S3 services, it is missing a number of
features:
+This is a pretty bare bone start for the S3 services, it is missing a number
of features:
- It does not do UTF8 encoding (as required)
- It does not deal with canonicalization of AMZ headers.
diff --git a/doc/admin-guide/plugins/slice.en.rst
b/doc/admin-guide/plugins/slice.en.rst
index 58cc610..06ae34e 100644
--- a/doc/admin-guide/plugins/slice.en.rst
+++ b/doc/admin-guide/plugins/slice.en.rst
@@ -164,7 +164,7 @@ restored.
For each of these blocks separate sequential TSHttpConnect(s) are made
back into the front end of ATS and all of the remap plugins are rerun.
-Slice skips the remap due to presense of the X-Slicer-Info header and
+Slice skips the remap due to presence of the X-Slicer-Info header and
allows cache_range_requests.so to serve the slice block back to Slice
either via cache OR parent request.
@@ -207,7 +207,7 @@ of bytes are actually transferred and cached.
Current Limitations
===================
-By restoring the prisine Url the plugin as it works today reuses the
+By restoring the pristine Url the plugin as it works today reuses the
same remap rule for each slice block. This is wasteful in that it reruns
the previous remap rules, and those remap rules must be smart enough to
check for the existence of any headers they may have created the
diff --git a/doc/admin-guide/plugins/ssl_session_reuse.en.rst
b/doc/admin-guide/plugins/ssl_session_reuse.en.rst
index 5a728de..c253ff9 100644
--- a/doc/admin-guide/plugins/ssl_session_reuse.en.rst
+++ b/doc/admin-guide/plugins/ssl_session_reuse.en.rst
@@ -34,7 +34,7 @@ For Session ID base resumption in uses the ATS SSL Session
Cache for the local s
Redis to communication new sessions with its peers. When a new session is
seen by an ATS instances it
publishes an encrypted copy of the session state to the local Redis channel.
When a new session is received
on the Redis channel, the plugin stores that session state into its local ATS
SSL session cache. Once the
-session state is in the local ATS SSL session cache it is avalible to the
openssl library for future TLS
+session state is in the local ATS SSL session cache it is available to the
openssl library for future TLS
handshakes.
For the ticket based session resumption, the plugin implements logic to decide
on a Session Ticket Encryption Key (STEK)
@@ -43,7 +43,7 @@ to the other ATS boxes in the group. When the plugin starts
up, it will publish
resend the STEK key. The plugin uses the TSSslTicketKeyUpdate call to update
ATS with the last two STEK's it has received.
All communication over the Redis channel is encrypted with a preshared key.
All the ATS boxes participating in the session
-resuse must have access to that preshared key.
+reuse must have access to that preshared key.
Building
========
@@ -52,7 +52,7 @@ This plugin uses Redis for communication. The hiredis client
development librar
for this plugin to build. It can be installed in the standard system location
or the install location
can be specified by the --with-hiredis argument to configure.
-As part of the expermental plugs, the --enable-experimental-plugins option
must also be given to configure
+As part of the experimental plugs, the --enable-experimental-plugins option
must also be given to configure
to build this plugin.
Deploying
@@ -60,7 +60,7 @@ Deploying
The SSL Session Reuse plugin relies on Redis for communication. To deploy
build your own redis server or use a standard rpm
package. It must be installed on at least one box in the ATS group. We have
it installed on two boxes in a failover
-scenario. The SSL Session Resuse configuration file describes how to
communicate with the redis servers.
+scenario. The SSL Session Reuse configuration file describes how to
communicate with the redis servers.
* :ts:cv:`proxy.config.ssl.session_cache` should be set to 2 to enable the ATS
implementation of session cache
* :ts:cv:`proxy.config.ssl.session_cache.size` and
:ts:cv:`proxy.config.ssl.session_cache.num_buckets` may need to be adjusted to
ensure good hash table performance for your workload. For example, we needed
to increase the number of buckets to avoid long hash chains.
@@ -74,7 +74,7 @@ SSL Session Reuse is a global plugin. Its configuration file
is given as a argu
* redis.RedisEndpoints - This is a comma separated list of Redis servers to
connect to. The description of the redis server may include a port
* redis.RedisConnectTimeout - Timeout on the redis connect attempt in
milliseconds.
-* redis.RedisRetryDelay - Timeout on retrying redis operations in miliseconds.
+* redis.RedisRetryDelay - Timeout on retrying redis operations in milliseconds.
* pubconfig.PubNumWorkers - Number of worker threads. Must be at least as
many as the number of redis servers.
* pubconfig.PubRedisPublishTries - Number of times to attempt publishing data
* pubconfig.PubRedisConnectTries - Number of times to retry a redis connection
attempt
diff --git a/doc/admin-guide/plugins/sslheaders.en.rst
b/doc/admin-guide/plugins/sslheaders.en.rst
index 49a8777..9559112 100644
--- a/doc/admin-guide/plugins/sslheaders.en.rst
+++ b/doc/admin-guide/plugins/sslheaders.en.rst
@@ -75,7 +75,7 @@ Examples:
---------
In this example, the origin server is interested in the subject of
-the server certificate that was used to accept a client connetion.
+the server certificate that was used to accept a client connection.
We can apply the ``sslheaders`` plugin to a generic remap rule to
provide this information. The :file:`remap.config` configuration
would be::
diff --git a/doc/admin-guide/plugins/tcpinfo.en.rst
b/doc/admin-guide/plugins/tcpinfo.en.rst
index 83c2ca8..f705548 100644
--- a/doc/admin-guide/plugins/tcpinfo.en.rst
+++ b/doc/admin-guide/plugins/tcpinfo.en.rst
@@ -110,10 +110,10 @@ The following options may be specified in
:file:`plugin.config`:
:ts:cv:`proxy.config.output.logfile.rolling_enabled` setting in
:file:`records.config`
for the ``tcpinfo`` plugin. The setting may range from ``0`` to ``3``.
``0`` disables logfile rolling. ``1`` is the ``default`` and enables logfile
- rolling at specfic intervals set by ``--rolling-interval-sec`` discussed
+ rolling at specific intervals set by ``--rolling-interval-sec`` discussed
below. ``2`` enables logfile rolling by logfile size, see
``--rolling-size-mb`` below. Finally a value of ``3`` enables logfile
rolling
- at specfic intervals or size, whichever occurs first using the interval or
size
+ at specific intervals or size, whichever occurs first using the interval or
size
settings discussed below.
--rolling-offset-hr=VALUE
diff --git a/doc/admin-guide/plugins/url_sig.en.rst
b/doc/admin-guide/plugins/url_sig.en.rst
index 242fac8..ad108fd 100644
--- a/doc/admin-guide/plugins/url_sig.en.rst
+++ b/doc/admin-guide/plugins/url_sig.en.rst
@@ -186,7 +186,7 @@ Key Index
Parts
Configures which components of the URL to use for signature verification.
- The value of this parameter is a string of ones and zeroes, each enabling
+ The value of this parameter is a string of ones and zeros, each enabling
or disabling the use of a URL part for signatures. The URL scheme (e.g.
``http://``) is never part of the signature. The first number of this
parameter's value indicates whether to include the FQDN, and all remaining
diff --git a/doc/admin-guide/plugins/xdebug.en.rst
b/doc/admin-guide/plugins/xdebug.en.rst
index a9eeac7..bb5f376 100644
--- a/doc/admin-guide/plugins/xdebug.en.rst
+++ b/doc/admin-guide/plugins/xdebug.en.rst
@@ -60,7 +60,7 @@ Diags
Probe
All request and response headers are written to the response body. Because
the body is altered, it disables writing to cache.
- In conjuction with the `fwd` tag, the response body will contain a
+ In conjunction with the `fwd` tag, the response body will contain a
chronological log of all headers for all transactions used for this
response.
diff --git a/doc/admin-guide/security/index.en.rst
b/doc/admin-guide/security/index.en.rst
index 84586c2..7be8dd9 100644
--- a/doc/admin-guide/security/index.en.rst
+++ b/doc/admin-guide/security/index.en.rst
@@ -138,7 +138,7 @@ Client/Traffic Server connections, you must do the
following:
=====
=======================================================================
``0`` Client certificates not required.
``1`` Client certificates optional. If present, will be used to validate.
- ``2`` Client certficates required, and must validate based on configured
CAs.
+ ``2`` Client certificates required, and must validate based on configured
CAs.
=====
=======================================================================
#. *Optional*: Configure the use of Certification Authorities (CAs). CAs add
@@ -274,7 +274,7 @@ revocation status of all configured SSL certificates, and
present them to the
client when the client requests the status. Traffic Server will automatically
query the OCSP responder specified in the SSL certificate to gather the latest
revocation status. Traffic Server will then cache the results for each
-configured certifcate. The location of the OCSP responder is taken from the
+configured certificate. The location of the OCSP responder is taken from the
Authority Information Access field of the signed certificate. For example::
Authority Information Access:
diff --git a/doc/admin-guide/storage/index.en.rst
b/doc/admin-guide/storage/index.en.rst
index dd0c22f..50e1e63 100644
--- a/doc/admin-guide/storage/index.en.rst
+++ b/doc/admin-guide/storage/index.en.rst
@@ -406,7 +406,7 @@ with a ``304 Not Modified`` HTTP message.
This table describes how Traffic Server handles these types of requests: ::
- OS = Origin Server's respose HTTP message
+ OS = Origin Server's response HTTP message
IMS = A GET request w/ an If-Modified-Since header
LMs = Last-Modified header date returned by server
INM = A GET request w/ an If-None-Match header
diff --git a/doc/appendices/command-line/traffic_cache_tool.en.rst
b/doc/appendices/command-line/traffic_cache_tool.en.rst
index 99f3897..40d8822 100644
--- a/doc/appendices/command-line/traffic_cache_tool.en.rst
+++ b/doc/appendices/command-line/traffic_cache_tool.en.rst
@@ -48,7 +48,7 @@ be abbreviated to any unique initial substring (e.g. "--sp"
for "--span").
.. option:: --spans
Specify the span (storage) configuration. This can be a device, a cache
directory, or a
- configuration file in the formof :file:`storage.config`. In the latter
case all devices listed
+ configuration file in the form of :file:`storage.config`. In the latter
case all devices listed
in the configuration file become active.
.. option:: --volumes
diff --git a/doc/appendices/command-line/traffic_ctl.en.rst
b/doc/appendices/command-line/traffic_ctl.en.rst
index 86066ce..7489b83 100644
--- a/doc/appendices/command-line/traffic_ctl.en.rst
+++ b/doc/appendices/command-line/traffic_ctl.en.rst
@@ -288,7 +288,7 @@ endpoint.
:option:`--time` is included the host is marked down for the specified
number of seconds after
which the host will automatically be marked up. A host is not marked up
until all reason codes
are cleared by marking up the host for the specified reason code.
-
+
Supports :option:`--time`, :option:`--reason`.
.. option:: up HOSTNAME [HOSTNAME ...]
@@ -312,8 +312,8 @@ Mark down a host with `traffic_ctl` and view the associated
host stats::
proxy.process.host_status.cdn-cache-02.foo.com
HOST_STATUS_UP,ACTIVE:UP:0:0,LOCAL:UP:0:0,MANUAL:UP:0:0,SELF_DETECT:UP:0
proxy.process.host_status.cdn-cache-origin-01.foo.com
HOST_STATUS_UP,ACTIVE:UP:0:0,LOCAL:UP:0:0,MANUAL:UP:0:0,SELF_DETECT:UP:0
-In the example above, 'cdn-cache-01.foo.com' is unavailable,
`HOST_STATUS_DOWN` and was marked down
-for the `manual` reason, `MANUAL:DOWN:1556896844:0`, at the time indicated by
the UNIX time stamp
+In the example above, 'cdn-cache-01.foo.com' is unavailable,
`HOST_STATUS_DOWN` and was marked down
+for the `manual` reason, `MANUAL:DOWN:1556896844:0`, at the time indicated by
the UNIX time stamp
`1556896844`. To make the host available, one would have to clear the
`manual` reason using ::
$ traffic_ctl host up cdn-cache-01.foo.com --reason manual
diff --git a/doc/appendices/command-line/traffic_logcat.en.rst
b/doc/appendices/command-line/traffic_logcat.en.rst
index d78795f..953f939 100644
--- a/doc/appendices/command-line/traffic_logcat.en.rst
+++ b/doc/appendices/command-line/traffic_logcat.en.rst
@@ -30,7 +30,7 @@ Synopsis
Description
===========
-To analyse a binary log file using standard tools, you must first convert
+To analyze a binary log file using standard tools, you must first convert
it to ASCII. :program:`traffic_logcat` does exactly that.
Options
diff --git a/doc/appendices/command-line/traffic_wccp.en.rst
b/doc/appendices/command-line/traffic_wccp.en.rst
index 2df924c..6d4bb6d 100644
--- a/doc/appendices/command-line/traffic_wccp.en.rst
+++ b/doc/appendices/command-line/traffic_wccp.en.rst
@@ -46,7 +46,7 @@ Options
.. option:: --address IP address to bind.
-.. option:: --router Booststrap IP address for routers.
+.. option:: --router Bootstrap IP address for routers.
.. option:: --service Path to service group definitions.
diff --git a/doc/appendices/faq.en.rst b/doc/appendices/faq.en.rst
index a953ae0..4e45fa4 100644
--- a/doc/appendices/faq.en.rst
+++ b/doc/appendices/faq.en.rst
@@ -498,7 +498,7 @@ Config checker
--------------
Traffic Server supports the below command to validate the config offline, in
order to
-allow the config to be pre-checked for possible service disruptions due to
synatx errors::
+allow the config to be pre-checked for possible service disruptions due to
syntax errors::
traffic_server -Cverify_config -D<config_dir>
diff --git a/doc/developer-guide/api/functions/TSHttpHookAdd.en.rst
b/doc/developer-guide/api/functions/TSHttpHookAdd.en.rst
index 3019be0..6443ae1 100644
--- a/doc/developer-guide/api/functions/TSHttpHookAdd.en.rst
+++ b/doc/developer-guide/api/functions/TSHttpHookAdd.en.rst
@@ -68,7 +68,7 @@ It is good practice to conserve resources by reusing hooks in
this way
when possible.
When a continuation on a hook is triggered, the name of the event passed to
-the continution function depends on the name of the hook. The naming
+the continuation function depends on the name of the hook. The naming
convention is that, for hook TS_xxx_HOOK, the event passed to the continuation
function will be TS_EVENT_xxx. For example, when a continuation attached to
TS_HTTP_READ_REQUEST_HDR_HOOK is triggered, the event passed to the
continuation
diff --git a/doc/developer-guide/api/functions/TSHttpParserCreate.en.rst
b/doc/developer-guide/api/functions/TSHttpParserCreate.en.rst
index a629ba8..e8974ac 100644
--- a/doc/developer-guide/api/functions/TSHttpParserCreate.en.rst
+++ b/doc/developer-guide/api/functions/TSHttpParserCreate.en.rst
@@ -68,7 +68,7 @@ may be used again.
:func:`TSHttpParserDestroy` destroys the TSHttpParser object pointed
to by :arg:`parser`. The :arg:`parser` pointer must not be NULL.
-Return Salues
+Return Values
=============
:func:`TSHttpHdrParseReq` and :func:`TSHttpHdrParseResp` both return
diff --git a/doc/developer-guide/api/functions/TSInstallDirGet.en.rst
b/doc/developer-guide/api/functions/TSInstallDirGet.en.rst
index 4025263..e9097a3 100644
--- a/doc/developer-guide/api/functions/TSInstallDirGet.en.rst
+++ b/doc/developer-guide/api/functions/TSInstallDirGet.en.rst
@@ -60,7 +60,7 @@ To load a file that is located in the Traffic Server
configuration directory::
char * path;
asprintf(&path, "%s/example.conf", TSConfigDirGet());
-See Slso
+See Also
========
:manpage:`TSAPI(3ts)`
diff --git a/doc/developer-guide/api/functions/TSLifecycleHookAdd.en.rst
b/doc/developer-guide/api/functions/TSLifecycleHookAdd.en.rst
index ced169b..0d150dc 100644
--- a/doc/developer-guide/api/functions/TSLifecycleHookAdd.en.rst
+++ b/doc/developer-guide/api/functions/TSLifecycleHookAdd.en.rst
@@ -180,7 +180,7 @@ initialization, which was problematic because all of them
could effectively
only be called from :func:`TSPluginInit` . The solution was to move
:func:`TSPluginInit` as early as possible in the process initialization and
provide hooks for API calls that needed to be invoked later which served
-essentially as additional pluging initialization points.
+essentially as additional plugin initialization points.
See Also
========
diff --git a/doc/developer-guide/api/functions/TSMimeHdrFieldAppend.en.rst
b/doc/developer-guide/api/functions/TSMimeHdrFieldAppend.en.rst
index 7690fa8..7866364 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
===========
-Attaches a MIME :arg:`field` to a header. The header is represented by the
:arg:`bufp` and :arg:`hdr`
+Attatches 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/api/functions/TSMimeHdrFieldValueStringGet.en.rst
b/doc/developer-guide/api/functions/TSMimeHdrFieldValueStringGet.en.rst
index b2541ad..7323753 100644
--- a/doc/developer-guide/api/functions/TSMimeHdrFieldValueStringGet.en.rst
+++ b/doc/developer-guide/api/functions/TSMimeHdrFieldValueStringGet.en.rst
@@ -103,7 +103,7 @@ This examples show how to retrieve and copy a specific
header. ::
return len;
}
-See Slso
+See Also
========
:manpage:`TSAPI(3ts)`,
diff --git a/doc/developer-guide/api/functions/TSSslContext.en.rst
b/doc/developer-guide/api/functions/TSSslContext.en.rst
index 9337895..415e644 100644
--- a/doc/developer-guide/api/functions/TSSslContext.en.rst
+++ b/doc/developer-guide/api/functions/TSSslContext.en.rst
@@ -36,7 +36,7 @@ Description
===========
:func:`TSSslContextFindByName` searches for a SSL server context
-created from :file:`ssl_multicert.config`, matchingg against the
+created from :file:`ssl_multicert.config`, matching against the
server :arg:`name`.
:func:`TSSslContextFindByAddr` searches for a SSL server context
diff --git a/doc/developer-guide/api/functions/TSSslServerContextCreate.en.rst
b/doc/developer-guide/api/functions/TSSslServerContextCreate.en.rst
index 38f982b..4cae064 100644
--- a/doc/developer-guide/api/functions/TSSslServerContextCreate.en.rst
+++ b/doc/developer-guide/api/functions/TSSslServerContextCreate.en.rst
@@ -37,7 +37,7 @@ Description
:func:`TSSslServerContextCreate` creates a new TLS server context. The context
is configured using the TLS settings specified in :file:`records.config`. The
user can pass certificate object(:type:`TSSslX509` :arg:`cert`
and certname (:code:`const char*` :arg:`certname`) optionally.
-This function sets the certificate status callback and initializes ocsp
stapling data if :arg:`cert` and :arg:`certname` is provided and ocsp is
enabled globally.
+This function sets the certificate status callback and initializes OCSP
stapling data if :arg:`cert` and :arg:`certname` is provided and ocsp is
enabled globally.
:func:`TSSslServerContextCreate` returns ``nullptr`` on failure.
:func:`TSSslContextDestroy` destroys a TLS context created by
diff --git a/doc/developer-guide/api/functions/TSSslSession.en.rst
b/doc/developer-guide/api/functions/TSSslSession.en.rst
index 321f34f..d0870a1 100644
--- a/doc/developer-guide/api/functions/TSSslSession.en.rst
+++ b/doc/developer-guide/api/functions/TSSslSession.en.rst
@@ -46,8 +46,8 @@ The functions also work with the :type:`TSSslSession` object
which can be cast t
These functions perform the appropriate locking on the session cache to avoid
errors.
-The :func:`TSSslSessionGet` and :func:`TSSslSessionGetBuffer` functions
retrieve the :type:`TSSslSession` object that is identifed by the
-:type:`TSSslSessionID` object. If there is no matching sesion object,
:func:`TSSslSessionGet` returns NULL and :func:`TSSslSessionGetBuffer`
+The :func:`TSSslSessionGet` and :func:`TSSslSessionGetBuffer` functions
retrieve the :type:`TSSslSession` object that is identified by the
+:type:`TSSslSessionID` object. If there is no matching session object,
:func:`TSSslSessionGet` returns NULL and :func:`TSSslSessionGetBuffer`
returns 0.
:func:`TSSslSessionGetBuffer` returns the session information serialized in a
buffer that can be shared between processes.
@@ -64,4 +64,4 @@ updating the session ticket encrypt key file with new data
and reloading the cur
require writing session ticket encryption keys to disk.
If both the ticket key files and :func:`TSSslTicketKeyUpdate` are used to
update session ticket encryption keys, ATS will use the most recent update
-reguarless if whether it was made by file and configuration reload or API.
+regardless if whether it was made by file and configuration reload or API.
diff --git a/doc/developer-guide/api/functions/TSTypes.en.rst
b/doc/developer-guide/api/functions/TSTypes.en.rst
index 675029a..d0f85d9 100644
--- a/doc/developer-guide/api/functions/TSTypes.en.rst
+++ b/doc/developer-guide/api/functions/TSTypes.en.rst
@@ -82,7 +82,7 @@ more widely. Those are described on this page.
.. type:: TSHttpSsn
- An opaque type that represents a Traffic SeUuirver :term:`session`.
+ An opaque type that represents a Traffic Server :term:`session`.
.. type:: TSHttpTxn
@@ -126,7 +126,7 @@ more widely. Those are described on this page.
.. type:: TSMLoc
This is a memory location relative to a :term:`header heap` represented by
a :c:type:`TSMBuffer` and
- must always be used in conjuction with that :c:type:`TSMBuffer` instance.
It identifies a specific
+ must always be used in conjunction with that :c:type:`TSMBuffer` instance.
It identifies a specific
object in the :c:type:`TSMBuffer`. This indirection is needed so that the
:c:type:`TSMBuffer`
can reallocate space as needed. Therefore a raw address obtained from a
:c:type:`TSMLoc` should
be considered volatile that may become invalid across any API call.
@@ -209,7 +209,7 @@ more widely. Those are described on this page.
.. cpp:class:: template<typename T> DLL
- An anchor for a double linked instrusive list of instance of :arg:`T`.
+ An anchor for a double linked intrusive list of instance of :arg:`T`.
.. cpp:class:: template<typename T> Queue
diff --git a/doc/developer-guide/api/functions/TSUuidCreate.en.rst
b/doc/developer-guide/api/functions/TSUuidCreate.en.rst
index 9f91650..7def6f3 100644
--- a/doc/developer-guide/api/functions/TSUuidCreate.en.rst
+++ b/doc/developer-guide/api/functions/TSUuidCreate.en.rst
@@ -101,7 +101,7 @@ return status code, :type:`TSReturnCode`. You should verify
the success of
those APIs, of course.
The :func:`TSUuidStringGet` function will return ``NULL`` if the :type:`TSUuid`
-object is not properly inititialized. Likewise, :func:`TSUuidVersionGet` would
+object is not properly initialized. Likewise, :func:`TSUuidVersionGet` would
then return ``TS_UUID_UNDEFINED``.
The :func:`TSUuidDestroy` function can not fail, and does not have a return
diff --git a/doc/developer-guide/api/functions/TSVConnReenable.en.rst
b/doc/developer-guide/api/functions/TSVConnReenable.en.rst
index ff3aba0..a7075fc 100644
--- a/doc/developer-guide/api/functions/TSVConnReenable.en.rst
+++ b/doc/developer-guide/api/functions/TSVConnReenable.en.rst
@@ -62,7 +62,7 @@ Synopsis
Description
===========
-An extended verion of TSVConnEnable that allows the plugin to return a status
to
+An extended version of TSVConnEnable that allows the plugin to return a status
to
the core logic. If all goes well this is TS_EVENT_CONTINUE. However, if
the plugin wants to stop the processing it can set the event to TS_EVENT_ERROR.
diff --git a/doc/developer-guide/api/types/TSMgmtTypes.en.rst
b/doc/developer-guide/api/types/TSMgmtTypes.en.rst
index 000aef3..6d53d22 100644
--- a/doc/developer-guide/api/types/TSMgmtTypes.en.rst
+++ b/doc/developer-guide/api/types/TSMgmtTypes.en.rst
@@ -93,7 +93,7 @@ Management Events
.. c:macro:: MGMT_EVENT_LIFECYCLE_MESSAGE
-OpTypes (Possible operations or msgs that can be sent between TM and remote
clients)
+OpTypes (Possible operations or messages that can be sent between TM and
remote clients)
====================================================================================
.. cpp:type:: OpType
diff --git a/doc/developer-guide/cache-architecture/architecture.en.rst
b/doc/developer-guide/cache-architecture/architecture.en.rst
index 84a0408..f09e79c 100644
--- a/doc/developer-guide/cache-architecture/architecture.en.rst
+++ b/doc/developer-guide/cache-architecture/architecture.en.rst
@@ -51,7 +51,7 @@ Cache Layout
============
The following sections describe how persistent cache data is structured. |TS|
-treats its persisent storage as an undifferentiated collection of bytes,
+treats its persistent storage as an undifferentiated collection of bytes,
assuming no other structure to it. In particular, it does not use the file
system of the host operating system. If a file is used it is used only to mark
out the set of bytes to be used.
@@ -602,14 +602,14 @@ This value should be chosen so that it is a multiple of a
:ref:`cache entry multiplier <big-mult>`. It is not necessary to make it a
power of two [#cache-mult-value]_. Larger fragments increase I/O efficiency but
lead to more wasted space. The default size (1M, 2^20) is a reasonable choice
-in most circumstances, altough in very specific cases there can be benefit from
+in most circumstances, although in very specific cases there can be benefit
from
tuning this parameter. |TS| imposes an internal maximum of a 4,194,232 bytes,
which is 4M (2^22), less the size of a struct :cpp:class:`Doc`. In practice,
the largest reasonable target fragment size is 4M - 262,144 = 3,932,160.
When a fragment is stored to disk, the size data in the cache index entry is
set to the finest granularity permitted by the size of the fragment. To
-determine this, consult the :ref:`cache entry multipler <big-mult>` table and
+determine this, consult the :ref:`cache entry multiplier <big-mult>` table and
find the smallest maximum size that is at least as large as the fragment. That
will indicate the value of *big* selected and therefore the granularity of the
approximate size. That represents the largest possible amount of wasted disk
I/O
@@ -982,8 +982,8 @@ to evacuate. It is assumed that an evacuation block is
placed in the evacuation
bucket (array element) that corresponds to the evacuation region in which the
fragment is located although no ordering per bucket is enforced in the linked
list (this sorting is handled during evacuation). Objects are evacuated by
-specifying the first or earliest fragment in the evactuation block. The
-evactuation operation will then continue the evacuation for subsequent
fragments
+specifying the first or earliest fragment in the evacuation block. The
+evacuation operation will then continue the evacuation for subsequent fragments
in the object by adding those fragments in evacuation blocks. Note that the
actual evacuation of those fragments is delayed until the write cursor reaches
the fragments, it is not necessarily done at the time the earliest fragment is
@@ -1029,7 +1029,7 @@ written out in turn. Because the fragment data is now in
memory it is acceptable
to overwrite the disk image.
Note that when normal stripe writing is resumed, this same check is done again,
-each time evauating (if needed) a fragment and queuing them for writing in
turn.
+each time evaluating (if needed) a fragment and queuing them for writing in
turn.
Updates to the directory are done when the write for the evacuated fragment
completes. Multi-fragment objects are detected after the read completes for a
diff --git a/doc/developer-guide/cache-architecture/cache-initialization.en.rst
b/doc/developer-guide/cache-architecture/cache-initialization.en.rst
index 7e5b902..91fe64f 100644
--- a/doc/developer-guide/cache-architecture/cache-initialization.en.rst
+++ b/doc/developer-guide/cache-architecture/cache-initialization.en.rst
@@ -62,7 +62,7 @@ all of those have completed, the resulting storage is
distributed across the
Stripe Assignment
=================
-Every object that is stored in stored in a single, specific stripe. Stripe
assignment is determing
+Every object that is stored in stored in a single, specific stripe. Stripe
assignment is determining
for an object what stripe that is. The logic described here sets up the stripe
assignment table maps
from the cache key to a specific stripe.
@@ -131,7 +131,7 @@ can be seen as the arrow color in the previous figure. This
provides a reasonabl
size assignment of slots to stripes. It is also a consistent hash in that if a
stripe is removed,
the recomputation will tend to distribute assignments for the missing stripe
across the other
stripes in proportion to their sizes while not changing the assignment of any
slot not assigned to
-the missing stripe. In essence for each sample point (assignment slot) a
permuation of the stripes
+the missing stripe. In essence for each sample point (assignment slot) a
permutation of the stripes
is implied by the order of the random value nodes past that sample point. The
randomization serves
to spread re-assigned slots to various stripes instead of a single one.
diff --git a/doc/developer-guide/cache-architecture/consistency.en.rst
b/doc/developer-guide/cache-architecture/consistency.en.rst
index c5d5faf..94d168c 100644
--- a/doc/developer-guide/cache-architecture/consistency.en.rst
+++ b/doc/developer-guide/cache-architecture/consistency.en.rst
@@ -163,7 +163,7 @@ identical. Plugins can change the cache key, or not,
depending on any data in
the request header. For instance, not changing the cache key if the request is
not in the ``doc`` directory. If distinguishing servers is important, that can
easily be pulled from the request URL and used in the synthetic cache key. The
-implementor is free to extract all relevant elements for use in the cache key.
+implementer is free to extract all relevant elements for use in the cache key.
While there is no explicit requirement that the synthetic cache key be based on
the HTTP request header, in practice it is generally necessary due to the
diff --git a/doc/developer-guide/cache-architecture/data-structures.en.rst
b/doc/developer-guide/cache-architecture/data-structures.en.rst
index 09355c7..3974eb7 100644
--- a/doc/developer-guide/cache-architecture/data-structures.en.rst
+++ b/doc/developer-guide/cache-architecture/data-structures.en.rst
@@ -103,7 +103,7 @@ Data Structures
.. class:: CacheHTTPInfoVector
Defined in :ts:git:`iocore/cache/P_CacheHttp.h`. This is an array of
:class:`HTTPInfo`
- objects and serves as the respository of information about alternates of an
+ objects and serves as the repository of information about alternates of an
object. It is marshaled as part of the metadata for an object in the cache.
.. class:: HTTPInfo
@@ -396,7 +396,7 @@ Data Structures
.. member:: int volume_number
- indentification number of this volume
+ identification number of this volume
.. member:: int scheme
@@ -453,7 +453,7 @@ Data Structures
.. member:: int num_http_volumes
- Total number of volumes scpecified in volume.config for HTTP scheme
+ Total number of volumes specified in volume.config for HTTP scheme
.. member:: Queue<ConfigVol> cp_queue
diff --git a/doc/developer-guide/cache-architecture/tiered-storage.en.rst
b/doc/developer-guide/cache-architecture/tiered-storage.en.rst
index faaf4be..2448e97 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 recieves the object stream. For tiered storage, the same thing is done
+which receieves 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/client-session-architecture.en.rst
b/doc/developer-guide/client-session-architecture.en.rst
index 7df36aa..6d238f2 100644
--- a/doc/developer-guide/client-session-architecture.en.rst
+++ b/doc/developer-guide/client-session-architecture.en.rst
@@ -28,7 +28,7 @@ submitting sequences of requests over the session. ATS
supports several session
HTTP/1.x and HTTP/2. A HTTP State Machine is created for each request to
process the request.
ATS uses the generic classes ProxyClientSession and ProxyClientTransaction to
hide the details of
-the underlaying protocols from the HTTP State Machine.
+the underlying protocols from the HTTP State Machine.
Classes
=======
@@ -54,7 +54,7 @@ ProxyClientTransaction
:alt: ProxyClientTransaction hierarchy
The ProxyClientTransaction class abstracts the key features of a client
transaction. It has a reference to its
-paraent ProxyClientSession. One HttpSM is created for each
ProxyClientTransaction.
+parent ProxyClientSession. One HttpSM is created for each
ProxyClientTransaction.
There are two concrete subclasses: Http1ClientTransaction and Http2Stream.
@@ -72,7 +72,7 @@ This diagram shows the relationships between objects created
as part of a HTTP/1
object performs the basic network level protocols. The Http1ClientSession
object has a reference to the
associated NetVC object. The NetVC object is available via the
:code:`ProxyClientSession::get_netvc()` method.
-The Http1ClientSession object contains a Http1ClientTransaction objet. For
each HTTP request, it calls
+The Http1ClientSession object contains a Http1ClientTransaction object. For
each HTTP request, it calls
the :code:`ProxyClientSession::new_transaction()` method to instantiate the
Http1ClientTransaction object. With the HTTP/1.x
protocol at most one transaction can be active at a time.
@@ -104,7 +104,7 @@ Transaction and Session Shutdown
One of the trickiest bits of managing sessions and transactions is cleaning
things up accurately and in a timely fashion.
In addition, the TXN_CLOSE hooks and SSN_CLOSE hooks must be executed
accurately. The TXN_CLOSE hooks must be
-executely exactly once. The SSN_CLOSE hook must also be executed exactly once
and only after all the TXN_CLOSE
+executed exactly once. The SSN_CLOSE hook must also be executed exactly once
and only after all the TXN_CLOSE
hooks of all the child transactions have been executed. The CLOSE hooks are
important for many plugins to ensure that
plugin allocated objects are appropriately reclaimed.
diff --git a/doc/developer-guide/config-vars.en.rst
b/doc/developer-guide/config-vars.en.rst
index 5fa8808..5a25e64 100644
--- a/doc/developer-guide/config-vars.en.rst
+++ b/doc/developer-guide/config-vars.en.rst
@@ -93,9 +93,9 @@ type:``RecT``
name:``char const*``
The fully qualified name of the configuration variable. Although there
- appears to be a hierarchial naming scheme, that's just a convention, and it
+ appears to be a hierarchical naming scheme, that's just a convention, and it
is not actually used by the code. Nonetheless, new variables should adhere
- to the hierarchial scheme.
+ to the hierarchical scheme.
value_type:``RecDataT``
The data type of the value. It should be one of ``RECD_INT``,
@@ -172,7 +172,7 @@ generally via :option:`traffic_ctl config reload`. This is
handled in a generic
described in the next section, or in a :ref:`more specialized way
<http-config-var-impl>`
(built on top of the generic mechanism) for HTTP related configuration
variables. This is only needed if the variable is marked as dynamically
-updateable (|RECU_DYNAMIC|_) although HTTP configuration variables should be
+updatable (|RECU_DYNAMIC|_) although HTTP configuration variables should be
dynamic if possible.
Documentation and Defaults
@@ -260,11 +260,11 @@ action.
The callback occurs asynchronously. For HTTP variables as described in the
next section, this is handled by the more specialized HTTP update
mechanisms.
- Otherwise it is the implementor's responsibility to avoid race conditions.
+ Otherwise it is the implementer's responsibility to avoid race conditions.
.. _http-config-var-impl:
-HTTP Configuation Values
+HTTP Configuration Values
------------------------
Variables used for HTTP processing should be declared as members of the
@@ -310,7 +310,7 @@ required for generic access:
#. Augment the ``TSHttpTxnConfigFind`` function to return this enumeration
value
when given the name of the configuration variable. Be sure to count the
- charaters very carefully.
+ characters very carefully.
#. Augment the ``_conf_to_memberp`` function in |InkAPI.cc|_ to return a
pointer
to the appropriate member of ``OverridableHttpConfigParams`` and set the
type
diff --git a/doc/developer-guide/debugging/debug-tags.en.rst
b/doc/developer-guide/debugging/debug-tags.en.rst
index 01192e4..7738ace 100644
--- a/doc/developer-guide/debugging/debug-tags.en.rst
+++ b/doc/developer-guide/debugging/debug-tags.en.rst
@@ -72,7 +72,7 @@ Server behavior for testing and analysis.
The debug tag setting (``-T`` and ``proxy.config.diags.debug.tags``) is a
anchored regular expression against which the tag for a specific debug
-message is matched. This means the value "http" matches debug emssages
+message is matched. This means the value "http" matches debug messages
with the tag "http" but also "http\_seq" and "http\_trans". If you want
multiple tags then use a pipe symbol to separate the tags. For example
"http\_tproxy\|dns\|hostdb" will match any of the message tags
diff --git a/doc/developer-guide/host-resolution-proposal.en.rst
b/doc/developer-guide/host-resolution-proposal.en.rst
index af34e6f..a1a5272 100644
--- a/doc/developer-guide/host-resolution-proposal.en.rst
+++ b/doc/developer-guide/host-resolution-proposal.en.rst
@@ -27,7 +27,7 @@ The current mechanism for resolving host names to IP
addresses for Traffic Serve
libraries. These take hostnames and provide IP addresses for them.
The current implementation is generally considered inadequate, both from a
functionality point of view and difficulty in
-working with it in other parts of Traffic Server. As Traffic Server is used in
more complex situtations this inadequacy
+working with it in other parts of Traffic Server. As Traffic Server is used in
more complex situations this inadequacy
presents increasing problems.
Goals
@@ -146,7 +146,7 @@ The biggest hurdle is being able to unwind a resolver chain
when a block is enco
1) Set a maximum resolver chain length and declare the request instance so
that there is storage for state for that many
resolvers. If needed and additional value of maximum storage per chain could
be set as well. The expected number of
-elements in a chain is expected to be limited, 10 would likely be a reaosnable
limit. If settable at source
+elements in a chain is expected to be limited, 10 would likely be a reasonable
limit. If settable at source
configuration time this should be sufficient.
2) Embed class allocators in resolver chains and mark the top / outermost /
first resolver. The maximum state size for a
diff --git a/doc/developer-guide/internal-libraries/AcidPtr.en.rst
b/doc/developer-guide/internal-libraries/AcidPtr.en.rst
index 8d8ac71..22d6e04 100644
--- a/doc/developer-guide/internal-libraries/AcidPtr.en.rst
+++ b/doc/developer-guide/internal-libraries/AcidPtr.en.rst
@@ -48,7 +48,7 @@ Named after the desirable properties of a database, ACID_
acronym:
* Atomic - reads and writes avoid skew, by using mutex locks.
* Consistent - data can only be changed by a commit, and only one commit can
exist at a time per data.
-* Isolated - commits of a single point of data are not concurrent. But commits
of seperate data can be conncurrent.
+* Isolated - commits of a single point of data are not concurrent. But commits
of separate data can be concurrent.
* Durable - shared_ptr is used to keep older versions of data in memory while
references exist.
.. _ACID: https://en.wikipedia.org/wiki/ACID_(computer_science)
diff --git a/doc/developer-guide/internal-libraries/MemArena.en.rst
b/doc/developer-guide/internal-libraries/MemArena.en.rst
index 6b2bc02..ea5bc2f 100644
--- a/doc/developer-guide/internal-libraries/MemArena.en.rst
+++ b/doc/developer-guide/internal-libraries/MemArena.en.rst
@@ -65,7 +65,7 @@ of the copied objects will be put in the same new internal
block. If this for so
sizing isn't correct a hint can be passed to :func:`MemArena::freeze` to
specify a different value
(if, for instance, there is a lot of unused memory of known size). Generally
this is most useful for
data that is initialized on process start and not changed after process
startup. After the process
-start initilization, the data can be coalesced for better performance after
all modifications have
+start initialization, the data can be coalesced for better performance after
all modifications have
been done. Alternatively, a container that allocates and de-allocates same
sized objects (such as a
:code:`std::map`) can use a free list to re-use objects before going to the
|MemArena| for more
memory and thereby avoiding collecting unused memory in the arena.
@@ -148,6 +148,6 @@ Allocated memory is tracked by two linked lists, one for
current memory and the
memory. The latter is used only while the arena is frozen. Because a shared
pointer is used for the
link, the list can be de-allocated by clearing the head pointer in |MemArena|.
This pattern is
similar to that used by the :code:`IOBuffer` data blocks, and so those were
considered for use as
-the internal memory allcation blocks. However, that would have required some
non-trivial tweaks and,
+the internal memory allocation blocks. However, that would have required some
non-trivial tweaks and,
with the move away from internal allocation pools to memory support from
libraries like "jemalloc",
unlikely to provide any benefit.
diff --git a/doc/developer-guide/internal-libraries/TextView.en.rst
b/doc/developer-guide/internal-libraries/TextView.en.rst
index 1b38da2..da4849d 100644
--- a/doc/developer-guide/internal-libraries/TextView.en.rst
+++ b/doc/developer-guide/internal-libraries/TextView.en.rst
@@ -46,7 +46,7 @@ size. This is when makes it possible to pass sub strings
around without having t
allocation additional memory. This comes at the cost of keeping track of the
actual owner of the
string memory and making sure the :class:`TextView` does not outlive the
memory owner, just as with
a normal pointer type. Internal for |TS| any place that passes a :code:`char
*` and a size is an
-excellent candidate for using a :class:`TextView` as it is more convinient and
no more risky than
+excellent candidate for using a :class:`TextView` as it is more convenient and
no more risky than
the existing arguments.
In deciding between :code:`std::string_view` and :class:`TextView` remember
that these easily and
diff --git a/doc/developer-guide/internal-libraries/buffer-writer.en.rst
b/doc/developer-guide/internal-libraries/buffer-writer.en.rst
index 23d200d..5541caf 100644
--- a/doc/developer-guide/internal-libraries/buffer-writer.en.rst
+++ b/doc/developer-guide/internal-libraries/buffer-writer.en.rst
@@ -101,7 +101,7 @@ becomes::
"format string", args...));
By hiding the length tracking and checking, the result is a simple linear
sequence of output chunks,
-making the logic much eaier to follow.
+making the logic much easier to follow.
Usage
+++++
@@ -134,7 +134,7 @@ needs to be specified and therefore can simply be a
constant without the overhea
to maintain consistency. The choice between :class:`LocalBufferWriter` and
:class:`FixedBufferWriter`
comes down to the owner of the buffer - the former has its own buffer while
the latter operates on
a buffer owned by some other object. Therefore if the buffer is declared
locally, use
-:class:`LocalBufferWriter` and if the buffer is recevied from an external
source (such as via a
+:class:`LocalBufferWriter` and if the buffer is received from an external
source (such as via a
function parameter) use :class:`FixedBufferWriter`.
Writing
@@ -273,7 +273,7 @@ Formatted Output
++++++++++++++++
The base :class:`BufferWriter` was made to provide memory safety for formatted
output. Support for
-formmatted output was made to provide *type* safety. The implementation
deduces the types of the
+formatted output was made to provide *type* safety. The implementation deduces
the types of the
arguments to be formatted and handles them in a type specific and safe way.
The formatting style is of the "prefix" or "printf" style - the format is
specified first and then
@@ -314,7 +314,7 @@ As a result of these benefits there has been other work on
similar projects, to
:code:`printf` a better mechanism. Unfortunately most of these are rather
project specific and don't
suit the use case in |TS|. The two best options, `Boost.Format
<https://www.boost.org/doc/libs/1_64_0/libs/format/>`__ and `fmt
<https://github.com/fmtlib/fmt>`__,
-while good, are also not quite close enough to outweight the benefits of a
version specifically
+while good, are also not quite close enough to outweigh the benefits of a
version specifically
tuned for |TS|. ``Boost.Format`` is not acceptable because of the Boost
footprint. ``fmt`` has the
problem of depending on C++ stream operators and therefore not having the
required level of
performance or memory characteristics. Its main benefit, of reusing stream
operators, doesn't apply
@@ -488,8 +488,8 @@ Some examples, comparing :code:`snprintf` and
:func:`BufferWriter::print`. ::
Enumerations become easier. Note in this case argument indices are used in
order to print both a
name and a value for the enumeration. A key benefit here is the lack of need
for a developer to know
the specific free function or method needed to do the name lookup. In this
case,
-:code:`HttpDebugNuames::get_server_state_name`. Rather than every developer
having to memorize the
-assocation between the type and the name lookup function, or grub through the
code hoping for an
+:code:`HttpDebugNames::get_server_state_name`. Rather than every developer
having to memorize the
+association between the type and the name lookup function, or grub through the
code hoping for an
example, the compiler is told once and henceforth does the lookup. The
internal implementation of
this is :ref:`here <bwf-http-debug-name-example>` ::
@@ -550,7 +550,7 @@ would look like this::
BufferWriter& ts::bwformat(BufferWriter& w, BWFSpec const& spec, V const& v)
:arg:`w` is the output and :arg:`spec` the parsed specifier, including the
extension (if any). The
-calling framework will handle basic alignment as per :arg:`spec` therfore the
overload does not need
+calling framework will handle basic alignment as per :arg:`spec` therefore the
overload does not need
to unless the alignment requirements are more detailed (e.g. integer alignment
operations) or
performance is critical. In the latter case the formatter should make sure to
use at least the
minimum width in order to disable any additional alignment operation.
@@ -812,10 +812,10 @@ These are the existing format classes in header file
``bfw_std_format.h``. All a
As previous except the epoch is the current epoch at the time the
constructor is invoked.
Therefore if the current time is to be printed the default constructor
can be used.
- When used the format specification can take an extention of "local" which
formats the time as
+ When used the format specification can take an extension of "local" which
formats the time as
local time. Otherwise it is GMT. ``w.print("{}", Date("%H:%M"));`` will
print the hour and minute
as GMT values. ``w.print("{::local}", Date("%H:%M"));`` will When used the
format specification
- can take an extention of "local" which formats the time as local time.
Otherwise it is GMT.
+ can take an extension of "local" which formats the time as local time.
Otherwise it is GMT.
``w.print("{}", Date("%H:%M"));`` will print the hour and minute as GMT
values.
``w.print("{::local}", Date("%H:%M"));`` will print the hour and minute in
the local time zone.
``w.print("{::gmt}"), ...);`` will output in GMT if additional explicitness
is desired.
@@ -885,7 +885,7 @@ For example, to have the same output as the normal
diagnostic messages with a ti
bw.print("{timestamp} {ts-thread} Counter is {}", counter);
Note that even though no argument is provided the global names do not count as
part of the argument
-indexing, therefore the preceeding example could be written as::
+indexing, therefore the preceding example could be written as::
bw.print("{timestamp} {ts-thread} Counter is {0}", counter);
@@ -962,7 +962,7 @@ Reference
.. function:: BufferWriter & fill(size_t n)
Increase the output size by :arg:`n` without changing the buffer
contents. This is used in
- conjuction with :func:`BufferWriter::auxBuffer` after writing output to
the buffer returned by
+ conjunction with :func:`BufferWriter::auxBuffer` after writing output to
the buffer returned by
that method. If this method is not called then such output will not be
counted by
:func:`BufferWriter::size` and will be overwritten by subsequent output.
diff --git a/doc/developer-guide/internal-libraries/intrusive-hash-map.en.rst
b/doc/developer-guide/internal-libraries/intrusive-hash-map.en.rst
index 6f98a8b..8b5fbe3 100644
--- a/doc/developer-guide/internal-libraries/intrusive-hash-map.en.rst
+++ b/doc/developer-guide/internal-libraries/intrusive-hash-map.en.rst
@@ -120,7 +120,7 @@ Details
.. function:: iterator find(value_type * v)
- Search for :arg:`v` in the container. If found, return an iterator
refering to :arg:`v`. If not
+ Search for :arg:`v` in the container. If found, return an iterator
referring to :arg:`v`. If not
return the end iterator. This validates :arg:`v` is in the container.
.. function:: range equal_range(key_type key)
@@ -165,7 +165,7 @@ Design Notes
This is a refresh of an previously existing class, :code:`TSHahTable`. The
switch to C++ 11 and then
C++ 17 made it possible to do much better in terms of the internal
implementation and API. The
-overall functionality is the roughly the same but with an easier API,
compatiblity with
+overall functionality is the roughly the same but with an easier API,
compatibility with
:class:`IntrusiveDList`, improved compliance with STL container standards, and
better internal
implementation.
@@ -173,7 +173,7 @@ The biggest change is that elements are stored in a single
global list rather th
The buckets serve only as entry points in to the global list and to count the
number of elements
per bucket. This simplifies the implementation of iteration, so that the old
:code:`Location` nested
class can be removed. Elements with equal keys can be handled in the same way
as with STL
-containers, via iterator ranges, instead of a custom psuedo-iterator class.
+containers, via iterator ranges, instead of a custom pseudo-iterator class.
Notes on :func:`IntrusiveHashMap::apply`
========================================
diff --git a/doc/developer-guide/internal-libraries/intrusive-list.en.rst
b/doc/developer-guide/internal-libraries/intrusive-list.en.rst
index 3a33d55..2d49f44 100644
--- a/doc/developer-guide/internal-libraries/intrusive-list.en.rst
+++ b/doc/developer-guide/internal-libraries/intrusive-list.en.rst
@@ -20,7 +20,7 @@
IntrusiveDList
**************
-:class:`IntrusiveDList` is a class that provides a double linked list using
pointers embeded in the
+:class:`IntrusiveDList` is a class that provides a double linked list using
pointers embedded in the
object. :class:`IntrusiveDList` also acts as a queue. No memory management is
done - objects can be
added to and removed from the list but the allocation and deallocation of the
objects must be
handled outside the class. This class supports an STL compliant bidirectional
iteration. The
diff --git a/doc/developer-guide/internal-libraries/scalar.en.rst
b/doc/developer-guide/internal-libraries/scalar.en.rst
index 087c13c..84c28ff 100644
--- a/doc/developer-guide/internal-libraries/scalar.en.rst
+++ b/doc/developer-guide/internal-libraries/scalar.en.rst
@@ -28,8 +28,8 @@ of TS.Scalar are always multiples of the scale factor.
The tag is used to create categories of related types, the same underlying
"metric" at different scales. To enforce this TS.Scalar does not allow
assignment between instances with different tags. If this is not important the
tag can be omitted and a default generic one will be used, thereby allowing
arbitrary assignments.
-TS.Scalar is designed to be fast and efficient. When converting bewteen
similar types with different
-scales it will do the minimum amout of work while minimizing the risk of
integer overflow. Instances
+TS.Scalar is designed to be fast and efficient. When converting between
similar types with different
+scales it will do the minimum amount of work while minimizing the risk of
integer overflow. Instances
have the same memory footprint as the underlying integer storage type. It is
intended to replace
lengthy and error prone hand optimizations used to handle related values of
different scales.
@@ -53,7 +53,7 @@ quantizes the values that can be represented by an instance.
Imported template parameter :arg:`C`.
The scaling factor :arg:`SCALE` must be an positive integer. Values for an
instance will always
- be an integral multiple of :arg:`SCALE`. The alue of an instance will
always be a
+ be an integral multiple of :arg:`SCALE`. The value of an instance will
always be a
multiple of :arg:`SCALE`.
:arg:`C` must be an integral type. An instance of this type is used to hold
the internal
@@ -91,7 +91,7 @@ In normal use a scalar evaluates to its value rather than its
count. The goal is
instance that appears to store unscaled values in a quantized way. The count
is accessible if
needed.
-Assigment
+Assignment
=========
Assigning values to, from, and between :class:`Scalar` instances is usually
straightforward with a few simple rules.
@@ -143,7 +143,7 @@ The opposite is not implicit because the value of a
:code:`deka` can be one not
Note this is very different from using :func:`Scalar::assign`. The latter sets
the *count* of
the scalar instance. :code:`round_up` and :code:`round_down` set the *value*
of the scalar, dividing
-the provided value by the scale to set the count to make the value match the
assignment as closesly
+the provided value by the scale to set the count to make the value match the
assignment as closely
as possible.
.. code-block:: cpp
@@ -188,7 +188,7 @@ I/O
---
When a scalar is printed it prints out as its value, not count. For a family
of scalars it can be
-desireable to have the type printed along with the value. This can be done by
adding a member named
+desirable to have the type printed along with the value. This can be done by
adding a member named
:literal:`label` to the *tag* type of the scalar. If the :literal:`label`
member can be provided to
an I/O stream then it will be after the value of the scalar. Otherwise it is
ignored. An example can
be found in the <Bytes>_ section of the example usage.
@@ -198,7 +198,7 @@ Examples
The expected common use of TS.Scalar is to create a family of scalars
representing the same
underlying unit of measure, differing only in scale. The standard example of
this is computer memory
-sizezs which have this property and are quite frequently used in |TS|.
+sizes which have this property and are quite frequently used in |TS|.
Bytes
-----
@@ -260,5 +260,5 @@ operators act in the same way. The next step, to arithmetic
operators, is not so
require explicit scale indicators, such as :code:`round_down` or explicit
constructors. It was a
design goal to avoid, as much as possible, the requirement that the library
user keep track of the
scale of specific variables. This has proved very useful in practice, but at
the same time when
-doing arithmentic is is almost always the case that either the values are both
scalars (making the
+doing arithmetic is is almost always the case that either the values are both
scalars (making the
arithmetic unambiguous) or the scale of the literal is known (e.g., "add 6
kilobytes").
diff --git a/doc/developer-guide/plugins/example-plugins/tls_bridge.en.rst
b/doc/developer-guide/plugins/example-plugins/tls_bridge.en.rst
index 8cf444f..a657945 100644
--- a/doc/developer-guide/plugins/example-plugins/tls_bridge.en.rst
+++ b/doc/developer-guide/plugins/example-plugins/tls_bridge.en.rst
@@ -52,7 +52,7 @@ intercepted by the |Name| plugin inside |TS| if the
destination matches one of t
destinations. The plugin then makes a TLS connection to the peer |TS| using
the configured level of
security. The original ``CONNECT`` request from the Client to the ingress |TS|
is then sent to the
peer |TS| to create a connection from the peer |TS| to the Service. After this
the Client has a
-virtual circut to the Service and can use any TCP based communication
(including TLS). Effectively
+virtual circuit to the Service and can use any TCP based communication
(including TLS). Effectively
the plugin causes the explicit proxy to work as if the Client had done the
``CONNECT`` directly to
the peer |TS|. Note this means the DNS lookup for the Service is done by the
peer |TS|, not the
ingress |TS|.
@@ -164,7 +164,7 @@ useful case.
tls_bridge.so --file bridge.config .*[.]service[.]com peer.ats:4443
These are not identical - direct mappings and file mappings are processed
in order. This means in
- the first example, the direct mapping is checked before any mappping in
"bridge.config", and in
+ the first example, the direct mapping is checked before any mapping in
"bridge.config", and in
the latter example the mappings in "bridge.config" are checked before the
direct mappings. There
can be multiple "--file" arguments, which are processed in the order they
appear in
"plugin.config". The file name can be absolute, or relative. If the file
name is relative, it is
@@ -215,7 +215,7 @@ this
The key points are
* |TS| does no TLS negotiation at all. The properties of the connection
between the Ingress |TS|
- and the Service are completely determined by the Client and Server
negotation.
+ and the Service are completely determined by the Client and Server
negotiation.
* No packets are modified, the ""CLIENT HELLO"" sent by the Ingress |TS| is
an exact copy of that
sent to the Ingress |TS| by the Client. It is only examined for the SNI
data in order to select
the Service.
@@ -265,7 +265,7 @@ The overall exchange looks like the following:
Client <--> Service
lvc <-> ingress : <&arrow-thick-left> Move data <&arrow-thick-right>
ingress <-> rvc : <&arrow-thick-left> Move data <&arrow-thick-right>
- note over ingress : Plugin explicitlys moves this data.
+ note over ingress : Plugin explicitly moves this data.
@enduml
diff --git
a/doc/developer-guide/plugins/hooks-and-transactions/http-transactions.en.rst
b/doc/developer-guide/plugins/hooks-and-transactions/http-transactions.en.rst
index bc7ad15..f58bf3c 100644
---
a/doc/developer-guide/plugins/hooks-and-transactions/http-transactions.en.rst
+++
b/doc/developer-guide/plugins/hooks-and-transactions/http-transactions.en.rst
@@ -41,7 +41,7 @@ transaction and associate data to the transaction.
/*
* Simple plugin that illustrates:
* - how to register locally to a transaction
- * - how to deal with data that's associated with a tranaction
+ * - how to deal with data that's associated with a transaction
*
* Note: for readability, error checking is omitted
*/
@@ -148,7 +148,7 @@ transaction and associate data to the transaction.
and doesn't have any data associated with it */
contp = TSContCreate(global_hook_handler, NULL);
- /* Register gloabally */
+ /* Register globally */
TSHttpHookAdd(TS_HTTP_TXN_START_HOOK, contp);
}
diff --git a/doc/developer-guide/plugins/hooks-and-transactions/index.en.rst
b/doc/developer-guide/plugins/hooks-and-transactions/index.en.rst
index 0ffd5a4..f513795 100644
--- a/doc/developer-guide/plugins/hooks-and-transactions/index.en.rst
+++ b/doc/developer-guide/plugins/hooks-and-transactions/index.en.rst
@@ -155,7 +155,7 @@ HTTP Transaction State Diagram
TS_HTTP_TXN_CLOSE_HOOK [shape = box];
}
-HTTP Transacation Timers
+HTTP Transaction Timers
------------------------
For an overview of HTTP transaction timers, refer to the transaction timer
diagram
diff --git
a/doc/developer-guide/plugins/hooks-and-transactions/initiate-http-connection.en.rst
b/doc/developer-guide/plugins/hooks-and-transactions/initiate-http-connection.en.rst
index a732b96..9c42464 100644
---
a/doc/developer-guide/plugins/hooks-and-transactions/initiate-http-connection.en.rst
+++
b/doc/developer-guide/plugins/hooks-and-transactions/initiate-http-connection.en.rst
@@ -17,7 +17,7 @@
.. include:: ../../../common.defs
-.. _developer-pluings-hooks-initiate-http:
+.. _developer-plugins-hooks-initiate-http:
Initiate HTTP Connection
************************
diff --git
a/doc/developer-guide/plugins/hooks-and-transactions/ssl-session-api.en.rst
b/doc/developer-guide/plugins/hooks-and-transactions/ssl-session-api.en.rst
index 472d076..4da99fa 100644
--- a/doc/developer-guide/plugins/hooks-and-transactions/ssl-session-api.en.rst
+++ b/doc/developer-guide/plugins/hooks-and-transactions/ssl-session-api.en.rst
@@ -49,7 +49,7 @@ The following events can be sent to this callback
.. macro:: TS_EVENT_SSL_SESSION_GET
- Sent after a session has been fetched from the SSL session cache by a
client request. The plugin could update additional logginc and statistics.
+ Sent after a session has been fetched from the SSL session cache by a
client request. The plugin could update additional logging and statistics.
.. macro:: TS_EVENT_SSL_SESSION_REMOVE
diff --git a/doc/developer-guide/plugins/http-headers/mime-headers.en.rst
b/doc/developer-guide/plugins/http-headers/mime-headers.en.rst
index 7ab26e5..1ccf0da 100644
--- a/doc/developer-guide/plugins/http-headers/mime-headers.en.rst
+++ b/doc/developer-guide/plugins/http-headers/mime-headers.en.rst
@@ -80,7 +80,7 @@ specified by the functions (see the example in the
description of
**Note:** MIME headers may contain more than one MIME field with the
same name. Previous versions of Traffic Server joined multiple fields
with the same name into one field with composite values, but this
-behavior came at a performance cost and caused compatability issues with
+behavior came at a performance cost and caused compatibility issues with
older clients and servers. Hence, the current version of Traffic Server
does not coalesce duplicate fields. Correctly-behaving plugins should
check for the presence of duplicate fields and iterate over the
diff --git
a/doc/developer-guide/plugins/http-transformations/append-transform-plugin.en.rst
b/doc/developer-guide/plugins/http-transformations/append-transform-plugin.en.rst
index e3cfc57..f30b95c 100644
---
a/doc/developer-guide/plugins/http-transformations/append-transform-plugin.en.rst
+++
b/doc/developer-guide/plugins/http-transformations/append-transform-plugin.en.rst
@@ -78,7 +78,7 @@ what the function does:
- If the transformation vconnection has been closed, then
``append_transform`` calls ``my_data_destroy`` to destroy the
- vonnection.
+ vconnection.
- If ``append_transform`` receives an error event, then it calls
back the continuation to let it know it has completed the write
diff --git a/doc/developer-guide/plugins/http-transformations/index.en.rst
b/doc/developer-guide/plugins/http-transformations/index.en.rst
index 7e747d2..92f48ad 100644
--- a/doc/developer-guide/plugins/http-transformations/index.en.rst
+++ b/doc/developer-guide/plugins/http-transformations/index.en.rst
@@ -106,7 +106,7 @@ of bytes to be written. The **ndone** value is the current
progress, or
the number of bytes that have been written at a specific point in time.
When writing a transformation plugin, you must understand implementation
-as well as the use of ``VConnection``\ s. The *implementor's side*
+as well as the use of ``VConnection``\ s. The *implementer's side*
refers to how to implement a ``VConnection`` that others can use. At
minimum, a transform plugin creates a transformation that sits in the
data stream and must be able to handle the events that the upstream and
@@ -126,7 +126,7 @@ 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
-space. ``VConnection`` implementors use ``VIO``\ s to determine the
+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
made.
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 8a0dd1a..c6c20e7 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
@@ -98,7 +98,7 @@ Below is an overview of the null transform plugin:
transformation vconnection is ``null_transform``.
4. Get a handle to the output vconnection (that receives data from the
- tranformation).
+ transformation).
.. code-block:: c
diff --git a/doc/developer-guide/plugins/io/transformations.en.rst
b/doc/developer-guide/plugins/io/transformations.en.rst
index 826259e..e0135bb 100644
--- a/doc/developer-guide/plugins/io/transformations.en.rst
+++ b/doc/developer-guide/plugins/io/transformations.en.rst
@@ -22,16 +22,16 @@
Transformations
***************
-Vconnection Implementor's View
+Vconnection Implementer's View
==============================
-A VConnection implementor writes only transformations. All other
+A VConnection implementer writes only transformations. All other
VConnections (net VConnections and cache VConnections) are implemented
in iocore. As mentioned earlier, a given vconnection can have a maximum
of one read operation and one write operation being performed on it. The
vconnection user gets information about the operation being performed by
examining the VIO returned by a call to :c:func:`TSVConnRead` or
-:c:func:`TSVConnWrite`. The implementor, in turn, gets a handle on the VIO
+:c:func:`TSVConnWrite`. The implementer, in turn, gets a handle on the VIO
operation by examining the VIO returned by :c:func:`TSVConnReadVIOGet` or
:c:func:`TSVConnWriteVIOGet` (recall that every vconnection created through
the Traffic Server API has an associated read VIO and write VIO, even if
diff --git a/doc/developer-guide/plugins/io/vios.en.rst
b/doc/developer-guide/plugins/io/vios.en.rst
index 8048c78..ecd1a0c 100644
--- a/doc/developer-guide/plugins/io/vios.en.rst
+++ b/doc/developer-guide/plugins/io/vios.en.rst
@@ -26,7 +26,7 @@ A **VIO**, or **virtual IO**, is a description of an IO
operation that's
currently in progress. The VIO data structure is used by vconnection
users to determine how much progress has been made on a particular IO
operation and to re-enable an IO operation when it stalls due to buffer
-space issues. VIOs are used by vconnection implementors to determine the
+space issues. VIOs are used by vconnection implementers 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
made.
diff --git a/doc/developer-guide/plugins/mutexes.en.rst
b/doc/developer-guide/plugins/mutexes.en.rst
index 52e0a4e..6c63c0d 100644
--- a/doc/developer-guide/plugins/mutexes.en.rst
+++ b/doc/developer-guide/plugins/mutexes.en.rst
@@ -120,7 +120,7 @@ accessed by other continuations or processes. Here's how:
If any other functions want to access ``contp``'s data, then it is up to
them to get ``contp``'s mutex (using, for example, ``TSContMutexGet``)
-to lock it. For usage, ssee the sample Protocol plugin.
+to lock it. For usage, see the sample Protocol plugin.
How to Associate a Continuation With Every HTTP Transaction
===========================================================
@@ -197,7 +197,7 @@ In the plugin continuation handler, create the new
continuation
return 0;
}
-Remember that the ``txn_contp`` handler must destory itself when the
+Remember that the ``txn_contp`` handler must destroy itself when the
HTTP transaction is closed. If you forget to do this, then your plugin
will have a memory leak.
diff --git a/doc/developer-guide/release-process/index.en.rst
b/doc/developer-guide/release-process/index.en.rst
index e056ff1..ef7e4e7 100644
--- a/doc/developer-guide/release-process/index.en.rst
+++ b/doc/developer-guide/release-process/index.en.rst
@@ -96,7 +96,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.
-Send the release candiate announcement to the *users* and *dev* mailinging
+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
distribution files you uploaded. This announcement should also call for a vote
on the candidate, generally with a 72 hours time limit.
diff --git a/doc/developer-guide/testing-with-vagrant/index.en.rst
b/doc/developer-guide/testing-with-vagrant/index.en.rst
index c92c061..05e2fad 100644
--- a/doc/developer-guide/testing-with-vagrant/index.en.rst
+++ b/doc/developer-guide/testing-with-vagrant/index.en.rst
@@ -36,7 +36,7 @@ of operating systems and common distribution releases.
-- `VagrantUp website <https://www.vagrantup.com/about.html>`_
-Vagrant can be used in combination with any of the popular configurtion
+Vagrant can be used in combination with any of the popular configuration
management and automation tools, such as `Chef <https://www.chef.io/chef/>`_,
`Puppet <https://puppetlabs.com/>`_, `Ansible <http://www.ansible.com/home>`_,
and more. The Vagrantfile included in the |TS| repository happens to make use
diff --git a/doc/developer-guide/threads-and-events.en.rst
b/doc/developer-guide/threads-and-events.en.rst
index 6f3cbb0..3761b88 100644
--- a/doc/developer-guide/threads-and-events.en.rst
+++ b/doc/developer-guide/threads-and-events.en.rst
@@ -55,7 +55,7 @@ It is this class that provides support for using
:class:`Continuation` instances
overrides the :func:`Thread::execute` method to gain control after the
underlying thread is started.
This method executes a single continuation at thread start. If the thread is
:enumerator:
-`ThreadType::DEDICATED` it returns after invoking the start continuation. No
join is exectuted, the
+`ThreadType::DEDICATED` it returns after invoking the start continuation. No
join is executed, the
presumption is the start continuation will run until process termination. This
mechanism is used
because it is, from the |TS| point of view, the easiest to use because of the
common support of
continuations.
@@ -82,7 +82,7 @@ form
.. code-block:: cpp
- int ET_GROUP; // global variable, where "GROUP" is repalced by the actual
group / type name.
+ int ET_GROUP; // global variable, where "GROUP" is replaced by the actual
group / type name.
int n_group_threads = 3; // Want 3 of these threads by default, possibly
changed by configuration options.
constexpr size_t GROUP_STACK_SIZE = DEFAULT_STACK_SIZE; // stack size for
each thread.
void Group_Thread_Init(EThread*); // function to perform per thread local
initialization.
@@ -96,7 +96,7 @@ The function :code:`Group_Thread_Init` can be replaced with a
continuation if th
convenient. One advantage of a continuation is additional data (via
:arg:`cookie`) can be provide
during thread initialization.
-If there is no thread initializatoin needed, this can be compressed in to a
single call
+If there is no thread initialization needed, this can be compressed in to a
single call
.. code-block:: cpp
@@ -117,7 +117,7 @@ Types
.. var:: EventType ET_NET
- A synonymn for :var:`ET_CALL`.
+ A synonym for :var:`ET_CALL`.
.. var:: EventProcessor eventProcessor
@@ -160,7 +160,7 @@ Types
.. enumerator:: DEDICATED
- A thread which executes only the start contiuation and then exits.
+ A thread which executes only the start continuation and then exits.
.. enumerator:: REGULAR
diff --git a/doc/getting-started/index.en.rst b/doc/getting-started/index.en.rst
index 1713768..b6f76b8 100644
--- a/doc/getting-started/index.en.rst
+++ b/doc/getting-started/index.en.rst
@@ -260,7 +260,7 @@ settings have been configured as shown below::
This setting requires that a remap rule exist before |TS| will proxy the
request and ensures that your proxy cannot be used to access the content of
arbitrary websites (allowing someone of malicious intent to potentially
- mask their identity to an unknowning third party).
+ mask their identity to an unknowing third party).
:ts:cv:`proxy.config.url_remap.pristine_host_hdr`
This setting causes |TS| to keep the ``Host:`` client request header intact
