apache · mlibbey · Jun 17, 2020
diff --git a/doc/admin-guide/configuration/proxy-protocol.en.rst b/doc/admin-guide/configuration/proxy-protocol.en.rst
@@ -44,12 +44,12 @@ Proxy Protocol on a port.  Once enabled, all incoming requests must be prefaced
 with the PROXY v1 header.  Any request not preface by this header will be
 dropped.
 
-As a security measure, an optional whitelist of trusted IP addresses may be
+As a security measure, an optional allowlist of trusted IP addresses may be
 configured with :ts:cv:`proxy.config.http.proxy_protocol_whitelist`.
 
    .. important::
 
-       If the whitelist is configured, requests will only be accepted from these
+       If the allowlist is configured, requests will only be accepted from these
        IP addresses and must be prefaced with the PROXY v1 header.
 
 See :ts:cv:`proxy.config.http.insert_forwarded` for configuration information.

diff --git a/doc/admin-guide/files/records.config.en.rst b/doc/admin-guide/files/records.config.en.rst
@@ -1772,7 +1772,7 @@ Proxy User Variables
 
 .. ts:cv:: CONFIG proxy.config.http.proxy_protocol_whitelist STRING ```<ip list>```
 
-   This defines a whitelist of server IPs that are trusted to provide
+   This defines a allowlist of server IPs that are trusted to provide
    connections with Proxy Protocol information.  This is a comma delimited list
    of IP addresses.  Addressed may be listed individually, in a range separated
    by a dash or by using CIDR notation.

diff --git a/doc/admin-guide/plugins/cachekey.en.rst b/doc/admin-guide/plugins/cachekey.en.rst
@@ -179,10 +179,10 @@ Cache key structure and related plugin parameters
 ^^^^^^^^^^^^^^^
 
 * If no query related plugin parameters are used, the query string is included in the `cache key`.
-* ``--exclude-params`` (default: empty list) - comma-separated list of query params to be black-listed in the `cache key`. If the list is empty then no black-list is applied (no query parameters will be excluded from the `cache key`). The exclude list overrides the include list.
-* ``--include-params`` (default: empty list) - comma-separated list of query params to be white-listed in the `cache key`. If the list is empty then no white-list is applied (all query parameters will be included in the `cache key`).
-* ``--include-match-params`` (default: empty list) - regular expression matching query parameter names which will be white-listed in the `cache key`.
-* ``--exclude-match-params`` (default: empty list) - regular expression matching query parameter names which will be black-listed in the `cache key`.
+* ``--exclude-params`` (default: empty list) - comma-separated list of query params to be block-listed in the `cache key`. If the list is empty then no block-list is applied (no query parameters will be excluded from the `cache key`). The exclude list overrides the include list.
+* ``--include-params`` (default: empty list) - comma-separated list of query params to be allow-listed in the `cache key`. If the list is empty then no allow-list is applied (all query parameters will be included in the `cache key`).
+* ``--include-match-params`` (default: empty list) - regular expression matching query parameter names which will be allow-listed in the `cache key`.
+* ``--exclude-match-params`` (default: empty list) - regular expression matching query parameter names which will be block-listed in the `cache key`.
 * ``--remove-all-params`` (boolean:``true|false``, ``0|1``, ``yes|no``, default: ``false``) - if equals ``true`` then all query parameters are removed (the whole query string) and all other URI query parameter related settings (if used) will have no effect.
 * ``--sort-params`` (boolean:``true|false``, ``0|1``, ``yes|no``, default: ``false``) - if equals ``true`` then all query parameters are sorted in an increasing case-sensitive order
 
@@ -377,7 +377,7 @@ The following will make sure only query parameters ``a`` and ``c`` will be used
 
 If the URI has the following query string ``c=1&a=1&b=2&x=1&k=1&u=1&y=1`` the `cache key` will use ``c=1&a=1``
 
-White-list + black-list certain parameters using multiple parameters in the same remap rule.
+Allow-list + block-list certain parameters using multiple parameters in the same remap rule.
 """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 If the plugin is used with the following plugin parameters in the remap rule: ::
 
@@ -390,7 +390,7 @@ If the plugin is used with the following plugin parameters in the remap rule: ::
 
 and if the URI has the following query string ``c=1&a=1&b=2&x=1&k=1&u=1&y=1`` the `cache key` will use ``c=1&b=1``
 
-White-list + black-list certain parameters using multiple parameters in the same remap rule and regular expressions (PCRE).
+Allow-list + block-list certain parameters using multiple parameters in the same remap rule and regular expressions (PCRE).
 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 If the plugin is used with the following plugin parameters in the remap rule: ::
 
@@ -570,7 +570,7 @@ If the plugin is used with the following plugin parameter::
 
 then ``Mozilla/5.0_AppleWebKit/537.75.14`` will be used when constructing the key.
 
-User-Agent white-list classifier
+User-Agent allow-list classifier
 """"""""""""""""""""""""""""""""
 If the plugin is used with the following plugin parameter::
 
@@ -585,7 +585,7 @@ and if ``browser_agents.config`` contains: ::
 
 then ``browser`` will be used when constructing the key.
 
-User-Agent black-list classifier
+User-Agent block-list classifier
 """"""""""""""""""""""""""""""""
 If the plugin is used with the following plugin parameter::
 

diff --git a/doc/developer-guide/api/functions/TSAPI.en.rst b/doc/developer-guide/api/functions/TSAPI.en.rst
@@ -59,11 +59,11 @@ type.
 
 Possible uses for plugins include the following:
 
-* HTTP processing plugins can filter, blacklist, authorize users or transform content.
+* HTTP processing plugins can filter, blocklist, authorize users or transform content.
 
 * Protocol plugins can enable Traffic Server to proxy-cache new protocol content.
 
-* A blacklisting plugin denies attempts to access web sites that are off-limits.
+* A blocklisting plugin denies attempts to access web sites that are off-limits.
 
 * Append transform plugins add data to HTTP response content.
 

diff --git a/doc/developer-guide/introduction/index.en.rst b/doc/developer-guide/introduction/index.en.rst
@@ -53,15 +53,15 @@ Below is a section-by-section breakdown of this guide:
    How to compile and load plugins. Walks through a simple "hello world"
    example; explains how to initialize and register plugins. Basic structures
    that all plugins use: events, continuations, and how to hook on to |TS|
-   processes. Detailed explication of a sample blacklisting plugin.
+   processes. Detailed explication of a sample blocklisting plugin.
 
 :ref:`developer-plugins-examples-query-remap`
    This chapter demonstrates on a practical example how you can
    exploit the Traffic Server remap API for your plugins.
 
 :ref:`developer-plugins-header-based-examples`
    Detailed explanation about writing plugins that work on HTTP
-   headers; discusses sample blacklisting and basic authorization
+   headers; discusses sample blocklisting and basic authorization
    plugins.
 
 :ref:`developer-plugins-http-transformations`

diff --git a/...ng-the-transaction-being-processed.en.rst → ...ng-the-transaction-being-processed.en.rst b/...ng-the-transaction-being-processed.en.rst → ...ng-the-transaction-being-processed.en.rst
@@ -17,7 +17,7 @@
 
 .. include:: ../../../../common.defs
 
-.. _developer-plugins-blacklist-access-process-txn:
+.. _developer-plugins-blocklist-access-process-txn:
 
 Accessing the Transaction Being Processed
 *****************************************
@@ -38,12 +38,12 @@ The key here is that if the event is an HTTP transaction event, then the
 data passed to the continuation's handler is of type ``TSHttpTxn`` (a
 data type that represents HTTP transactions). Your plugin can then do
 things with the transaction. Here's how it looks in the code for the
-Blacklist plugin's handler:
+Blocklist plugin's handler:
 
 .. code-block:: c
 
    static int
-   blacklist_plugin (TSCont contp, TSEvent event, void *edata)
+   blocklist_plugin (TSCont contp, TSEvent event, void *edata)
    {
       TSHttpTxn txnp = (TSHttpTxn) edata;
       switch (event) {
@@ -60,5 +60,5 @@ Blacklist plugin's handler:
    }
 
 For example: when the origin server DNS lookup event is sent,
-``blacklist_plugin`` can call ``handle_dns``\ and pass ``txnp`` as an
+``blocklist_plugin`` can call ``handle_dns``\ and pass ``txnp`` as an
 argument.
diff --git a/...ns/example-plugins/blacklist/index.en.rst → ...ns/example-plugins/blocklist/index.en.rst b/...ns/example-plugins/blacklist/index.en.rst → ...ns/example-plugins/blocklist/index.en.rst
@@ -17,21 +17,21 @@
 
 .. include:: ../../../../common.defs
 
-.. _developer-plugins-examples-blacklist:
+.. _developer-plugins-examples-blocklist:
 
-Blacklist Plugin
+Blocklist Plugin
 ****************
 
-The sample blacklisting plugin included in the Traffic Server SDK is
-``blacklist_1.c``. This plugin checks every incoming HTTP client request
-against a list of blacklisted web sites. If the client requests a
-blacklisted site, then the plugin returns an ``Access forbidden``
+The sample blocklisting plugin included in the Traffic Server SDK is
+``blocklist_1.c``. This plugin checks every incoming HTTP client request
+against a list of blocklisted web sites. If the client requests a
+blocklisted site, then the plugin returns an ``Access forbidden``
 message to the client.
 
-The flow of HTTP processing with the blacklist plugin is illustrated in
-the figure titled :ref:`BlackListPlugin`.
+The flow of HTTP processing with the blocklist plugin is illustrated in
+the figure titled :ref:`BlockListPlugin`.
 This example also contains a simple configuration management interface.
-It can read a list of blacklisted sites from a file (``blacklist.txt``)
+It can read a list of blocklisted sites from a file (``blocklist.txt``)
 that can be updated by a Traffic Server administrator. When the
 configuration file is updated, Traffic Server sends an event to the
 plugin that wakes it up to do some work.
@@ -52,7 +52,7 @@ Traffic Server has a multi-threaded design, race conditions can occur if
 several threads try to access the same continuation's data.
 
 Here is how the static parent continuation is created in
-``blacklist_1.c``:
+``blocklist_1.c``:
 
 .. code-block:: c
 
@@ -62,20 +62,20 @@ Here is how the static parent continuation is created in
       // ...
       TSCont contp;
 
-      contp = TSContCreate (blacklist_plugin, NULL);
+      contp = TSContCreate (blocklist_plugin, NULL);
       // ...
    }
 
-The handler function for the plugin is ``blacklist_plugin``, and the
+The handler function for the plugin is ``blocklist_plugin``, and the
 mutex is null. The continuation handler function's job is to handle the
-events that are sent to it; accordingly, the ``blacklist_plugin``
+events that are sent to it; accordingly, the ``blocklist_plugin``
 routine consists of a switch statement that covers each of the events
 that might be sent to it:
 
 .. code-block:: c
 
    static int
-   blacklist_plugin (TSCont contp, TSEvent event, void *edata)
+   blocklist_plugin (TSCont contp, TSEvent event, void *edata)
    {
       TSHttpTxn txnp = (TSHttpTxn) edata;
       switch (event) {
@@ -86,18 +86,18 @@ that might be sent to it:
             handle_response (txnp);
             return 0;
          default:
-            TSDebug ("blacklist_plugin", "This event was unexpected: %d", );
+            TSDebug ("blocklist_plugin", "This event was unexpected: %d", );
             break;
       }
       return 0;
    }
 
 When you write handler functions, you have to anticipate any events that
 might be sent to the handler by hooks or by other functions. In the
-Blacklist plugin, ``TS_EVENT_OS_DNS`` is sent because of the global hook
+Blocklist plugin, ``TS_EVENT_OS_DNS`` is sent because of the global hook
 established in ``TSPluginInit``, ``TS_EVENT_HTTP_SEND_RESPONSE_HDR`` is
 sent because the plugin contains a transaction hook
-(see :ref:`developer-plugins-examples-blacklist-txn-hook`).
+(see :ref:`developer-plugins-examples-blocklist-txn-hook`).
 It is good practice to have a default case in your switch statements.
 
 .. toctree::

diff --git a/...ns/blacklist/setting-a-global-hook.en.rst → ...ns/blocklist/setting-a-global-hook.en.rst b/...ns/blacklist/setting-a-global-hook.en.rst → ...ns/blocklist/setting-a-global-hook.en.rst
@@ -23,7 +23,7 @@ Setting a Global Hook
 Global hooks are always added in ``TSPluginInit`` using
 ``TSHttpHookAdd``. The two arguments of ``TSHttpHookAdd`` are the hook
 ID and the continuation to call when processing the event corresponding
-to the hook. In ``blacklist_1.c``, the global hook is added as follows:
+to the hook. In ``blocklist_1.c``, the global hook is added as follows:
 
 .. code-block:: c
 
@@ -32,7 +32,7 @@ to the hook. In ``blacklist_1.c``, the global hook is added as follows:
 Above, ``TS_HTTP_OS_DNS_HOOK`` is the ID for the origin server DNS
 lookup hook and ``contp`` is the parent continuation created earlier.
 
-This means that the Blacklist plugin is called at every origin server
-DNS lookup. When it is called, the handler functio ``blacklist_plugin``
+This means that the Blocklist plugin is called at every origin server
+DNS lookup. When it is called, the handler functio ``blocklist_plugin``
 receives ``TS_EVENT_HTTP_OS_DNS`` and calls ``handle_dns`` to see if the
 request is forbidden.
diff --git a/...list/setting-up-a-transaction-hook.en.rst → ...list/setting-up-a-transaction-hook.en.rst b/...list/setting-up-a-transaction-hook.en.rst → ...list/setting-up-a-transaction-hook.en.rst
@@ -17,24 +17,24 @@
 
 .. include:: ../../../../common.defs
 
-.. _developer-plugins-examples-blacklist-txn-hook:
+.. _developer-plugins-examples-blocklist-txn-hook:
 
 Setting Up a Transaction Hook
 *****************************
 
-The Blacklist plugin sends "access forbidden" messages to clients if
-their requests are directed to blacklisted hosts. Therefore, the plugin
+The Blocklist plugin sends "access forbidden" messages to clients if
+their requests are directed to blocklisted hosts. Therefore, the plugin
 needs a transaction hook so it will be called back when Traffic Server's
 HTTP state machine reaches the "send response header" event. In the
-Blacklist plugin's ``handle_dns`` routine, the transaction hook is added
+Blocklist plugin's ``handle_dns`` routine, the transaction hook is added
 as follows:
 
 .. code-block:: c
 
    TSMutexLock (sites_mutex);
    for (i = 0; i < nsites; i++) {
       if (strncmp (host, sites[i], host_length) == 0) {
-         printf ("blacklisting site: %s\n", sites[i]);
+         printf ("blocklisting site: %s\n", sites[i]);
          TSHttpTxnHookAdd (txnp,
             TS_HTTP_SEND_RESPONSE_HDR_HOOK,
             contp);
@@ -50,10 +50,10 @@ as follows:
    TSHttpTxnReenable (txnp, TS_EVENT_HTTP_CONTINUE);
 
 This code fragment shows some interesting features. The plugin is
-comparing the requested site to the list of blacklisted sites. While the
-plugin is using the blacklist, it must acquire the mutex lock for the
-blacklist to prevent configuration changes in the middle of a
-blacklisting operation. If the requested site is blacklisted, then the
+comparing the requested site to the list of blocklisted sites. While the
+plugin is using the blocklist, it must acquire the mutex lock for the
+blocklist to prevent configuration changes in the middle of a
+blocklisting operation. If the requested site is blocklisted, then the
 following things happen:
 
 #. A transaction hook is added with ``TSHttpTxnHookAdd``; the plugin is
@@ -66,7 +66,7 @@ following things happen:
    ``TS_EVENT_HTTP_ERROR`` as its event argument. Reenabling with an
    error event tells the HTTP state machine to stop the transaction and
    jump to the "send response header" state. Notice that if the
-   requested site is not blacklisted, then the transaction is reenabled
+   requested site is not blocklisted, then the transaction is reenabled
    with the ``TS_EVENT_HTTP_CONTINUE`` event.
 
 #. The string and ``TSMLoc`` data stored in the marshal buffer ``bufp`` is

diff --git a/...mple-plugins/blacklist/source-code.en.rst → ...mple-plugins/blocklist/source-code.en.rst b/...mple-plugins/blacklist/source-code.en.rst → ...mple-plugins/blocklist/source-code.en.rst
@@ -17,20 +17,20 @@
 
 .. include:: ../../../../common.defs
 
-.. _developer-plugins-examples-blacklist-code:
+.. _developer-plugins-examples-blocklist-code:
 
 Sample Source Code
 ******************
 
-.. _blacklist-1.c:
+.. _blocklist-1.c:
 
-blacklist_1.c
+blocklist_1.c
 -------------
 
-The sample blacklisting plugin included in the Traffic Server SDK is
-``blacklist_1.c``. This plugin checks every incoming HTTP client request
-against a list of blacklisted web sites. If the client requests a
-blacklisted site, then the plugin returns an ``Access forbidden``
+The sample blocklisting plugin included in the Traffic Server SDK is
+``blocklist_1.c``. This plugin checks every incoming HTTP client request
+against a list of blocklisted web sites. If the client requests a
+blocklisted site, then the plugin returns an ``Access forbidden``
 message to the client.
 
 This plugin illustrates:
@@ -43,5 +43,5 @@ This plugin illustrates:
 
 -  How to use the plugin configuration management interface
 
-.. literalinclude:: ../../../../../example/plugins/c-api/blacklist_1/blacklist_1.c
+.. literalinclude:: ../../../../../example/plugins/c-api/blocklist_1/blocklist_1.c
    :language: c
diff --git a/...working-with-http-header-functions.en.rst → ...working-with-http-header-functions.en.rst b/...working-with-http-header-functions.en.rst → ...working-with-http-header-functions.en.rst
@@ -17,12 +17,12 @@
 
 .. include:: ../../../../common.defs
 
-.. _developer-plugins-examples-blacklist-http-header-functions:
+.. _developer-plugins-examples-blocklist-http-header-functions:
 
 Working with HTTP Header Functions
 **********************************
 
-The Blacklist plugin examines the host header in every client
+The Blocklist plugin examines the host header in every client
 transaction. This is done in the ``handle_dns`` routine, using
 ``TSHttpTxnClientReqGet``, ``TSHttpHdrUrlGet``, and ``TSUrlHostGet``.
 
@@ -39,19 +39,19 @@ transaction. This is done in the ``handle_dns`` routine, using
    int host_length;
 
    if (TSHttpTxnClientReqGet(txnp, &bufp, &hdr_loc) != TS_SUCCESS) {
-      TSError("[blacklist] Couldn't retrieve client request header");
+      TSError("[blocklist] Couldn't retrieve client request header");
       goto done;
    }
 
    if (TSHttpHdrUrlGet(bufp, hdr_loc, &url_loc) != TS_SUCCESS) {
-      TSError("[blacklist] Couldn't retrieve request url");
+      TSError("[blocklist] Couldn't retrieve request url");
       TSHandleMLocRelease(bufp, TS_NULL_MLOC, hdr_loc);
       goto done;
    }
 
    host = TSUrlHostGet(bufp, url_loc, &host_length);
    if (!host) {
-      TSError("[blacklist] couldn't retrieve request hostname");
+      TSError("[blocklist] couldn't retrieve request hostname");
       TSHandleMLocRelease(bufp, hdr_loc, url_loc);
       TSHandleMLocRelease(bufp, TS_NULL_MLOC, hdr_loc);
       goto done;

diff --git a/doc/developer-guide/plugins/example-plugins/index.en.rst b/doc/developer-guide/plugins/example-plugins/index.en.rst
@@ -26,7 +26,7 @@ Example Plugins
    :maxdepth: 2
 
    basic-authorization/index.en
-   blacklist/index.en
+   blocklist/index.en
    query_remap/index.en
    tls_bridge.en
 
@@ -47,7 +47,7 @@ understand the following topics:
 
 -  Working with HTTP header functions
 
-The two sample plugins discussed in this chapter are ``blacklist_1.c``
+The two sample plugins discussed in this chapter are ``blocklist_1.c``
 and ``basic_auth.c``. To build and install the example plugins use ::
 
    ./configure --enable-example-plugins