Cleanup trailing whitespaces, and YAML formatting

configs/strategies.yaml.default

@@ -7,30 +7,30 @@
 # The purpose of this file is to specify the strategies available for
 #   use in locating upstream caches for use to satisfy requests
 #
-# This is a YAML formatted file to define hosts, groups of hosts and next hop strategies that 
+# This is a YAML formatted file to define hosts, groups of hosts and next hop strategies that
 # may be used by remap
 #
 # There are three top-level YAML name spaces: 'hosts', 'groups', and 'strategies'.
-#   'hosts' is a YAML list of host's definitions and is used when defining 'groups' YAML 
-#     references are supported. 
-#   'groups' is a YAML list that aggregates a group of hosts together and serves as the 
-#     equivalent to the rings used in parent.config.  You may define upto five groups in a 
+#   'hosts' is a YAML list of host's definitions and is used when defining 'groups' YAML
+#     references are supported.
+#   'groups' is a YAML list that aggregates a group of hosts together and serves as the
+#     equivalent to the rings used in parent.config.  You may define upto five groups in a
 #     config, see MAX_GROUPS.
-#   'strategies' is a YAML list of strategy definitions. 
+#   'strategies' is a YAML list of strategy definitions.
 #
-# Files may be broken up into several different files.  The main file loaded by the Next Hop 
-# Strategy factory is this file, strategies.yaml.  You may move the 'hosts' and 'groups' 
-# definitions into separate files and then include them in this file using: 
+# Files may be broken up into several different files.  The main file loaded by the Next Hop
+# Strategy factory is this file, strategies.yaml.  You may move the 'hosts' and 'groups'
+# definitions into separate files and then include them in this file using:
 #
 #   '#include path_to_hosts_and_groups_file'
 #
-# It is even possible to put individual strategies into separate file.  The Next Hop 
-# strategy factory  concatenates all included files together in a single YAML document at 
+# It is even possible to put individual strategies into separate file.  The Next Hop
+# strategy factory  concatenates all included files together in a single YAML document at
 # each point where it sees an '#include file_name'.  When using this feature you just need to
 # ensure that the final concatenation is a valid YAML document with 'hosts', 'groups'
 # and 'strategies' in this given order.
 #
-# 
+#
 # This example YAML document shows a complete definiton in a single strategies.yaml
 # file.  There are other example unit test files in the source tree showing examples of
 # using '#include' and different formats available for use, proxy/http/remap/unit-tests/
@@ -40,7 +40,7 @@
 #
 #
 # hosts:
-#   - &p1 
+#   - &p1
 #     host: p1.foo.com
 #     hash_string: slsklslsk # optional hash string that replaces the hostname in consistent hashing.
 #     protocol:
@@ -59,14 +59,14 @@
 #       - scheme: https
 #         port: 443
 #         health_check_url: https://192.168.1.2:443
-#   - &s1 
+#   - &s1
 #     host: s1.foo.com
 #     hash_string: slsklslsk # optional hash string that replaces the hostname in consistent hashing.
 #     protocol:
 #       - scheme: http
 #         port: 80
 #         health_check_url: http://192.168.2.1:80
-#       - scheme: https 
+#       - scheme: https
 #         port: 443
 #         health_check_url: https://192.168.2.1:443
 #   - &s2
@@ -98,8 +98,8 @@
 #     groups: # groups of hosts, these groups are used as rings in consistent hash and arrays of host groups for round_robin.
 #       - *g1
 #       - *g2
-#     scheme: http 
-#     failover: 
+#     scheme: http
+#     failover:
 #       max_simple_retries: 2 # default is 1, indicates the maximum number of simple retries for the listed response codes.
 #       ring_mode: exhaust_ring # enumerated as exhaust_ring or alternate_ring
 #           #1) in 'exhaust_ring' mode all the servers in a ring are exhausted before failing over to secondary ring
@@ -113,20 +113,20 @@
 #         - active
 #   - strategy: 'mid-tier-south'
 #     policy: latched
-#     hash_key: uri 
-#     go_direct: false 
+#     hash_key: uri
+#     go_direct: false
 #     parent_is_proxy: false  # next hop hosts  are origin servers
 #     groups:
 #       - *g1
 #       - *g2
-#     scheme: https 
-#     failover: 
-#       max_simple_retries: 2 
+#     scheme: https
+#     failover:
+#       max_simple_retries: 2
 #       ring_mode: alternate_ring
 #       response_codes:
 #         - 404
 #         - 502
 #         - 503
-#       health_check: 
+#       health_check:
 #         - passive
 #         - active

doc/admin-guide/configuration/proxy-protocol.en.rst

@@ -31,7 +31,7 @@ TLS connections.
 
 .. note::
 
-    The current version only supports transforming client IP from PROXY Version 1 
+    The current version only supports transforming client IP from PROXY Version 1
     header to the Forwarded: header.
 
 In the current implementation, the client IP address in the PROXY protocol header

doc/admin-guide/files/sni.yaml.en.rst

@@ -97,7 +97,7 @@ client_key                The file containing the client private key that corres
                           |TS| tries to use a private key in client_cert.  Otherwise,
                           :ts:cv:`proxy.config.ssl.client.private_key.filename` is used.
 
-http2                     Indicates whether the H2 protocol should be added to or removed from the 
+http2                     Indicates whether the H2 protocol should be added to or removed from the
                           protocol negotiation list.  The valid values are :code:`on` or :code:`off`.
 
 disable_h2                Deprecated for the more general h2 setting.  Setting disable_h2

doc/admin-guide/files/strategies.yaml.en.rst

@@ -27,7 +27,7 @@ strategies.yaml
    :maxdepth: 2
 
 The :file:`strategies.yaml` file identifies the next hop proxies used in an
-cache hierarchy and the algorithms used to select the next hop proxy. Use 
+cache hierarchy and the algorithms used to select the next hop proxy. Use
 this file to perform the following configuration:
 
 -  Set up next hop cache hierarchies, with multiple parents and parent
@@ -50,7 +50,7 @@ and **strategies**.  These name spaces may be in separate files.  When in separa
 **#include filename** in the `strategies.yaml` so that they are concatenated by the strategy
 factory into a single YAML document in the order, **hosts**, **groups**, and the **strategies**.
 
-Alternatively if the config parameter `proxy.config.url_remap.strategies.filename` refers to 
+Alternatively if the config parameter `proxy.config.url_remap.strategies.filename` refers to
 a directory, the NextHopStrategyFactory will alphanumerically concatenate all files in that directory that end in `.yaml` by name into a single document stream for parsing.  The final document must be a vaild `YAML` document with single `strategies` node and optionally a single `hosts` and `groups` node.  Any **#include filename** strings are ignored when reading `.yaml` files in a directory.
 
 Hosts definitions
@@ -59,14 +59,14 @@ Hosts definitions
 The **hosts** definitions is a **YAML** list of hosts.  This list is **optional** but if not used, the
 **groups** list **must** include complete defintions for hosts.  See the **group** examples below.
 
-In the example below, **hosts** is a **YAML** list of hosts.  Each host entry  uses a **YAML** anchor, 
+In the example below, **hosts** is a **YAML** list of hosts.  Each host entry  uses a **YAML** anchor,
 **&p1** and **&p2** that may be used elsewhere in the **YAML** document to refer to hosts **p1** and **p2**.
 
 - **host**: the host value is a hostname string
 - **protocol**: a list of schemes, ports, and health check urls for  the host.
-- **healthcheck**: health check information with the **url** used to check 
+- **healthcheck**: health check information with the **url** used to check
   the hosts health by some external health check agent.
-  
+
 Example::
 
   hosts:
@@ -85,7 +85,7 @@ Example::
         - scheme: http
           port: 80
           health_check_url: http://192.168.1.2:80
-  
+
 Groups definitions
 ==================
 
@@ -111,52 +111,52 @@ Example using **YAML** anchors and references::
       	weight: 0.5
       - <<: *p4
         weight: 1.5
- 
+
 Explicitly defined Example, no **YAML** referenences::
 
   groups:
     - &g1
       - p1
         host: p1.foo.com
         protocol:
-          - scheme: http 
+          - scheme: http
             port: 80
             health_check_url: http://192.168.1.1:80
-          - scheme: https 
+          - scheme: https
             port: 443
             health_check_url: https://192.168.1.1:443
         weight: 0.5
       - p2
         host: p2.foo.com
         protocol:
-          - scheme: http 
+          - scheme: http
             port: 80
             health_check_url: http://192.168.1.2:80
-          - scheme: https 
+          - scheme: https
             port: 443
             health_check_url: https://192.168.1.2:443
         weight: 0.5
     - &g2
       - p3
         host: p3.foo.com
         protocol:
-          - scheme: http 
+          - scheme: http
             port: 80
             health_check_url: http://192.168.1.3:80
-          - scheme: https 
+          - scheme: https
             port: 443
             health_check_url: https://192.168.1.3:443
         weight: 0.5
       - p4
         host: p4.foo.com
         protocol:
-          - scheme: http 
+          - scheme: http
             port: 80
             health_check_url: http://192.168.1.4:80
-          - scheme: https 
+          - scheme: https
             port: 443
             health_check_url: https://192.168.1.4:443
-        weight: 0.5      
+        weight: 0.5
 
 Strategies defintions
 =====================
@@ -171,7 +171,7 @@ Each **strategy** in the list may using the following parameters::
 
    #. **rr_ip**: round robin selection using the modulus of the client IP
    #. **rr_strict**: strict round robin over the list of hosts in the primary group.
-   #. **first_live**: always selects the first host in the primary group.  Other hosts are selected when the first host fails.  
+   #. **first_live**: always selects the first host in the primary group.  Other hosts are selected when the first host fails.
    #. **latched**:  Same as **first_live** but primary selection sticks to whatever host was used by a previous transaction.
    #. **consistent_hash**: hosts are selected using a **hash_key**.
 
@@ -184,7 +184,7 @@ Each **strategy** in the list may using the following parameters::
    #. **path+fragment**: Same as **path** but adds the fragement portion of the URL.
    #. **cache_key**: Uses the hash key from the **cachekey** plugin.  defaults to **path** if the **cachekey** plugin is not configured on the **remap**.
    #. **url**: Creates a hash from the entire request url.
-   
+
 - **go_direct** - A boolean value indicating whether a transaction may bypass proxies and go direct to the origin. Defaults to **true**
 - **parent_is_proxy**: A boolean value which indicates if the groups of hosts are proxy caches or origins.  **true** (default) means all the hosts used in the reamp are trafficserver caches.  **false** means the hosts are origins that the next hop strategies may use for load balancing and/or failover.
 - **scheme** Indicates which scheme the strategy supports, *http* or *https*
@@ -236,4 +236,3 @@ Example:
           - 503
         health_check:
           - passive
-

doc/admin-guide/logging/formatting.en.rst

@@ -205,9 +205,9 @@ ctid  Client Request Client Transaction ID, a non-negative number for a transact
                      which is different for all currently-active transactions on the
                      same client connection.  For client HTTP/2 transactions, this
                      value is the stream ID for the transaction.
-ctpw  Client Request Client Transaction Priority Weight, the priority weight for the 
+ctpw  Client Request Client Transaction Priority Weight, the priority weight for the
                      underlying HTTP/2 protocol.
-ctpd  Client Request Client Transaction Priority Dependence, the transaction ID that 
+ctpd  Client Request Client Transaction Priority Dependence, the transaction ID that
                      the current transaction depends on for HTTP/2 priority logic.
 ===== ============== ==================================================================
 

doc/admin-guide/plugins/ja3_fingerprint.en.rst

@@ -36,7 +36,7 @@ effective way to detect malicious clients even when superficial details are modi
 JA3 is available `here <https://github.com/salesforce/ja3>`__.
 
 The calculated JA3 fingerprints are then appended to upstream request in the field ``X-JA3-Sig``
-(to be processed at upstream). If multiple duplicates exist for the field name, it will append to the last 
+(to be processed at upstream). If multiple duplicates exist for the field name, it will append to the last
 occurrence; if none exists, it will add such a field to the headers. The signatures can also be logged locally.
 
 Plugin Configuration
@@ -72,4 +72,3 @@ API changes with regard to opaque structures.
 There is a potential issue with very old TLS clients which can cause a crash in the plugin. This is
 due to a `bug in OpenSSL <https://github.com/openssl/openssl/pull/8756>`__ which should be fixed in
 a future release.
-

doc/admin-guide/plugins/slice.en.rst

@@ -5,9 +5,9 @@
   to you under the Apache License, Version 2.0 (the
   "License"); you may not use this file except in compliance
   with the License.  You may obtain a copy of the License at
- 
+
    http://www.apache.org/licenses/LICENSE-2.0
- 
+
   Unless required by applicable law or agreed to in writing,
   software distributed under the License is distributed on an
   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY

doc/admin-guide/plugins/ssl_session_reuse.en.rst

@@ -22,7 +22,7 @@
 SSL Session Reuse Plugin
 ************************
 
-This plugin coordinates session state data between ATS instances running in a group.  This should 
+This plugin coordinates session state data between ATS instances running in a group.  This should
 improve TLS session reuse (both ticket and ID based) for a set of machines fronted by some form of
 layer 4 connection load balancer.
 
@@ -31,14 +31,14 @@ How It Works
 
 The plugin coordinates TLS session reuse for both Session ID based resumption and ticket based resumption.
 For Session ID base resumption in uses the ATS SSL Session Cache for the local store of TLS sessions.  It uses
-Redis to communication new sessions with its peers.  When a new session is seen by an ATS instances it 
+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 available 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)
-master.  The master will periodically create a new STEK key and use the Redis channel to publish the new STEK key 
+master.  The master will periodically create a new STEK key and use the Redis channel to publish the new STEK key
 to the other ATS boxes in the group.  When the plugin starts up, it will publish a Redis message requesting the master to
 resend the STEK key.  The plugin uses the TSSslTicketKeyUpdate call to update ATS with the last two STEK's it has received.
 
@@ -48,7 +48,7 @@ reuse must have access to that preshared key.
 Building
 ========
 
-This plugin uses Redis for communication.  The hiredis client development library must be installed 
+This plugin uses Redis for communication.  The hiredis client development library must be installed
 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.
 
@@ -59,8 +59,8 @@ 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 Reuse configuration file describes how to communicate with the redis servers.  
+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 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.
@@ -70,7 +70,7 @@ scenario.  The SSL Session Reuse configuration file describes how to communicate
 Config File
 ===========
 
-SSL Session Reuse is a global plugin.  Its configuration file is given as a argument to the plugin. 
+SSL Session Reuse is a global plugin.  Its configuration file is given as a argument to the plugin.
 
 * 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.
@@ -91,4 +91,3 @@ Example Config File
 ===================
 
 .. literalinclude:: ../../../plugins/experimental/ssl_session_reuse/example_config.config
-

doc/developer-guide/api/functions/TSContCall.en.rst

@@ -51,11 +51,11 @@ If there is a mutex associated with :arg:`contp`, :func:`TSContCall` assumes tha
 value returned by the handler in :arg:`contp`.
 
 If :arg:`contp` has a mutex, the plugin must acquire the lock on the mutex for :arg:`contp` before calling
-:func:`TSContCall`. See :func:`TSContMutexGet` and :func:`TSMutexLockTry` for mechanisms for doing this. 
+:func:`TSContCall`. See :func:`TSContMutexGet` and :func:`TSMutexLockTry` for mechanisms for doing this.
 
 The most common case is the code called by :func:`TSContCall` must complete before further code is executed
 at the call site. An alternative approach to handling the locking directly would be to split the call site
-into two continuations, one of which is signalled (possibly via :func:`TSContCall`) from the original 
+into two continuations, one of which is signalled (possibly via :func:`TSContCall`) from the original
 :func:`TSContCall` target.
 
 Note mutexes returned by :func:`TSMutexCreate` are recursive mutexes, therefore if the lock is
@@ -69,4 +69,3 @@ shareable so that the same mutex can be used for multiple continuations.::
 In this example case, :code:`cont1` can assume the lock for :code:`cont2` is held. This should be
 considered carefully because for the same reason any thread protection between the continuations is
 removed. This works well for tightly coupled continuations that always operate in a fixed sequence.
-

doc/developer-guide/api/functions/TSVConnReenable.en.rst

@@ -68,8 +68,6 @@ An extended version of TSVConnEnable that allows the plugin to return a status t
 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.
 
-For example, in the case of the TS_SSL_VERIFY_SERVER_HOOK, the plugin make decide the 
-origin certificate is bad.  By calling TSVonnReenable with TS_EVENT_ERROR, the 
+For example, in the case of the TS_SSL_VERIFY_SERVER_HOOK, the plugin make decide the
+origin certificate is bad.  By calling TSVonnReenable with TS_EVENT_ERROR, the
 certificate check will error and the TLS handshake will fail.
-
-

doc/developer-guide/api/functions/TSVConnSslVerifyCTXGet.en.rst

@@ -33,7 +33,7 @@ Synopsis
 Description
 ===========
 
-Get the TSSslVerifyCTX object that corresponds to the certificates being verified for the SSL connection 
+Get the TSSslVerifyCTX object that corresponds to the certificates being verified for the SSL connection
 corresponding to :arg:`svc`.
 
 This value is only meaningful during the peer certificate verification callbacks, specifically during callbacks