trafficcontrol-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mitchell...@apache.org
Subject [trafficcontrol] 10/46: Fixed some syntax highlighting
Date Wed, 26 Sep 2018 13:51:27 GMT
This is an automated email from the ASF dual-hosted git repository.

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

commit e50a4fca1319e80f4fa67448f620ca9f9e8c9d04
Author: ocket8888 <ocket8888@gmail.com>
AuthorDate: Tue Sep 11 14:22:30 2018 -0600

    Fixed some syntax highlighting
---
 docs/Makefile                                      |   4 +-
 docs/source/admin/index.rst                        |  36 +++----
 .../admin/traffic_portal/usingtrafficportal.rst    |   8 +-
 docs/source/api/v12/user.rst                       |   4 +-
 docs/source/basics/caching_proxies.rst             | 113 ++++++++++++---------
 docs/source/basics/http_11.rst                     |  26 +++--
 docs/source/overview/traffic_monitor.rst           |  26 ++---
 docs/source/overview/traffic_ops.rst               |  14 ++-
 docs/source/overview/traffic_router.rst            |   8 +-
 9 files changed, 135 insertions(+), 104 deletions(-)

diff --git a/docs/Makefile b/docs/Makefile
index 733d700..786bf19 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -19,7 +19,7 @@
 #
 
 # You can set these variables from the command line.
-SPHINXOPTS    = 
+SPHINXOPTS    =
 SPHINXBUILD   = sphinx-build
 PAPER         = letter
 BUILDDIR      = build
@@ -68,7 +68,7 @@ $(BUILDDIR):
 	-mkdir $(BUILDDIR)
 
 html: $(BUILDDIR)
-	$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
+	$(SPHINXBUILD) -j 4 -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
 	@echo
 	@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
 
diff --git a/docs/source/admin/index.rst b/docs/source/admin/index.rst
index c010ed8..7de91d1 100644
--- a/docs/source/admin/index.rst
+++ b/docs/source/admin/index.rst
@@ -32,22 +32,22 @@ When installing a complete CDN from scratch, a sample recommended order
is:
 Once everything is installed, you will need to configure the servers to talk to each other.
You will also need Origin server(s), from which the Mid-Tier Cache(s) will obtain content.
An Origin server is simply an HTTP(S) server which serves the content you wish to cache on
the CDN.
 
 .. toctree::
-  :maxdepth: 3
+	:maxdepth: 3
 
-  traffic_ops/installation.rst
-  traffic_ops/default_profiles.rst
-  traffic_ops/migration_from_10_to_20.rst
-  traffic_ops/migration_from_20_to_22.rst
-  traffic_ops/configuration.rst
-  traffic_ops/using.rst
-  traffic_ops/extensions.rst
-  traffic_portal/installation.rst
-  traffic_portal/usingtrafficportal.rst
-  traffic_monitor.rst
-  traffic_monitor_golang.rst
-  traffic_router.rst
-  traffic_router/migrationto2-3.rst
-  traffic_stats.rst
-  traffic_server.rst
-  traffic_vault.rst
-  quick_howto/index.rst
+	traffic_ops/installation.rst
+	traffic_ops/default_profiles.rst
+	traffic_ops/migration_from_10_to_20.rst
+	traffic_ops/migration_from_20_to_22.rst
+	traffic_ops/configuration.rst
+	traffic_ops/using.rst
+	traffic_ops/extensions.rst
+	traffic_portal/installation.rst
+	traffic_portal/usingtrafficportal.rst
+	traffic_monitor.rst
+	traffic_monitor_golang.rst
+	traffic_router.rst
+	traffic_router/migrationto2-3.rst
+	traffic_stats.rst
+	traffic_server.rst
+	traffic_vault.rst
+	quick_howto/index.rst
diff --git a/docs/source/admin/traffic_portal/usingtrafficportal.rst b/docs/source/admin/traffic_portal/usingtrafficportal.rst
index 25b50a0..d6d3183 100644
--- a/docs/source/admin/traffic_portal/usingtrafficportal.rst
+++ b/docs/source/admin/traffic_portal/usingtrafficportal.rst
@@ -261,7 +261,7 @@ A table of your delivery services with the following columns:
 +-------------------------------+-----------------------------------------------------------------------------------------------------------------------+
 | Active                        | When this is set to false, Traffic Router will not serve
DNS or HTTP responses for this delivery service.             |
 +-------------------------------+-----------------------------------------------------------------------------------------------------------------------+
-| Type                          | The type of content routing this delivery service will
use. See :ref:`ds-types`.                                   |
+| Type                          | The type of content routing this delivery service will
use. See :ref:`ds-types`.                                      |
 +-------------------------------+-----------------------------------------------------------------------------------------------------------------------+
 | Protocol                      | The protocol to serve this delivery service to the clients
with:                                                      |
 |                               |                                                       
                                                               |
@@ -277,7 +277,7 @@ A table of your delivery services with the following columns:
 +-------------------------------+-----------------------------------------------------------------------------------------------------------------------+
 | DSCP                          | The DSCP value to mark IP packets to the client with. 
                                                               |
 +-------------------------------+-----------------------------------------------------------------------------------------------------------------------+
-| Signing Algorithm             | See :ref:`signed-urls`.                               
                                                            |
+| Signing Algorithm             | See :ref:`signed-urls`.                               
                                                               |
 |                               | - None                                                
                                                               |
 |                               | - URL Signature Keys                                  
                                                               |
 |                               | - URI Signing Keys                                    
                                                               |
@@ -290,9 +290,9 @@ A table of your delivery services with the following columns:
 |                               | - drop at edge (2 URLs that are the same except for  the
query string will match, and cache HIT, while the origin     |
 |                               |   will not see original query string in the request.) 
                                                               |
 |                               |                                                       
                                                               |
-|                               | Dropping query strings at the edge will preclude the use
of a Regex Remap Expression. See :ref:`regex-remap`.      |
+|                               | Dropping query strings at the edge will preclude the use
of a Regex Remap Expression. See :ref:`regex-remap`.         |
 |                               |                                                       
                                                               |
-|                               | To set the qstring without the use of regex remap, or for
further options, see :ref:`qstring-handling`.            |
+|                               | To set the qstring without the use of regex remap, or for
further options, see :ref:`qstring-handling`.               |
 +-------------------------------+-----------------------------------------------------------------------------------------------------------------------+
 | Last Updated                  | Timestamp when the delivery service was last updated. 
                                                               |
 +-------------------------------+-----------------------------------------------------------------------------------------------------------------------+
diff --git a/docs/source/api/v12/user.rst b/docs/source/api/v12/user.rst
index d7a0a6e..33cf1e3 100644
--- a/docs/source/api/v12/user.rst
+++ b/docs/source/api/v12/user.rst
@@ -529,9 +529,9 @@ Users
   +--------------------------+--------+--------------------------------------------------------------------------------------------------------------------------------------+
   | ``missLong``             | string | The longitude to use when the client cannot be found
in the CZF or the Geo lookup.                                                   |
   +--------------------------+--------+--------------------------------------------------------------------------------------------------------------------------------------+
-  | ``multiSiteOrigin``      |  bool  | Is the Multi Site Origin feature enabled for this
delivery service (0=false, 1=true). See :ref:`multi-site-origin`                |
+  | ``multiSiteOrigin``      |  bool  | Is the Multi Site Origin feature enabled for this
delivery service (0=false, 1=true). See :ref:`multi-site-origin`                   |
   +--------------------------+--------+--------------------------------------------------------------------------------------------------------------------------------------+
-  | ``multiSiteOriginAlgor`` |  bool  | Is the Multi Site Origin feature enabled for this
delivery service (0=false, 1=true). See :ref:`multi-site-origin`                |
+  | ``multiSiteOriginAlgor`` |  bool  | Is the Multi Site Origin feature enabled for this
delivery service (0=false, 1=true). See :ref:`multi-site-origin`                   |
   +--------------------------+--------+--------------------------------------------------------------------------------------------------------------------------------------+
   | ``orgServerFqdn``        | string | The origin server base URL (FQDN when used in this
instance, includes the                                                            |
   |                          |        | protocol (http:// or https://) for use in retrieving
content from the origin server.                                                 |
diff --git a/docs/source/basics/caching_proxies.rst b/docs/source/basics/caching_proxies.rst
index 2874473..b6570ea 100644
--- a/docs/source/basics/caching_proxies.rst
+++ b/docs/source/basics/caching_proxies.rst
@@ -41,7 +41,7 @@ types of proxies in use on the Internet today:
 
 |arrow| Reverse Proxy
 ---------------------
-	A reverse proxy acts on behalf of the origin server. The client is mostly unaware it is
communicating with a proxy and not the actual origin. All EDGE caches in a Traffic Control
CDN are reverse proxies. To the end user a Traffic Control based CDN appears as a reverse
proxy since it retrieves content from the origin server, acting on behalf of that origin server.
The client requests a URL that has a hostname which resolves to the reverse proxy's IP address
and, in compliance with the HT [...]
+A reverse proxy acts on behalf of the origin server. The client is mostly unaware it is communicating
with a proxy and not the actual origin. All EDGE caches in a Traffic Control CDN are reverse
proxies. To the end user a Traffic Control based CDN appears as a reverse proxy since it retrieves
content from the origin server, acting on behalf of that origin server. The client requests
a URL that has a hostname which resolves to the reverse proxy's IP address and, in compliance
with the HTT [...]
 
 .. seealso:: `ATS documentation on reverse proxy <https://docs.trafficserver.apache.org/en/latest/admin/reverse-proxy-http-redirects.en.html#http-reverse-proxy>`_.
 
@@ -52,7 +52,8 @@ from the cache and not from the origin server directly. For this example,
the re
 cache is: ``http://www-origin-cache.cdn.com http://www.origin.com``.
 
 ..  Note:: In the previous example minimal headers were shown on both the request and response.
In the examples that follow, the origin server response is more realistic.
-	::
+
+	.. code-block:: http
 
 		HTTP/1.1 200 OK
 		Date: Sun, 14 Dec 2014 23:22:44 GMT
@@ -82,12 +83,16 @@ The client is given the URL ``http://www-origin-cache.cdn.com/foo/bar/fun.html``
 
 6a. If the response is not in the cache:
 
-	1. The proxy uses DNS to get the IPv4 address for ``www.origin.com``, connect to it on port
80, and sends: ::
+	1. The proxy uses DNS to get the IPv4 address for ``www.origin.com``, connect to it on port
80, and sends:
 
-		GET /foo/bar/fun.html HTTP/1.1
-		Host: www.origin.com
+		.. code-block:: http
+
+			GET /foo/bar/fun.html HTTP/1.1
+			Host: www.origin.com
+
+	2. The origin server responds with the headers and content as shown:
 
-	2. The origin server responds with the headers and content as shown: ::
+		.. code-block:: http
 
 			HTTP/1.1 200 OK
 			Date: Sun, 14 Dec 2014 23:22:44 GMT
@@ -100,7 +105,9 @@ The client is given the URL ``http://www-origin-cache.cdn.com/foo/bar/fun.html``
 
 			<!DOCTYPE html><html><body>This is a fun file</body></html>
 
-	3. The proxy sends the origin response on to the client adding a ``Via:`` header (and maybe
others): ::
+	3. The proxy sends the origin response on to the client adding a ``Via:`` header (and maybe
others):
+
+		.. code-block:: http
 
 			HTTP/1.1 200 OK
 			Date: Sun, 14 Dec 2014 23:22:44 GMT
@@ -117,7 +124,9 @@ The client is given the URL ``http://www-origin-cache.cdn.com/foo/bar/fun.html``
 
 6b. If it *is* in the cache:
 
-	The proxy responds to the client with the previously retrieved result: ::
+	The proxy responds to the client with the previously retrieved result:
+
+	.. code-block:: http
 
 		HTTP/1.1 200 OK
 		Date: Sun, 14 Dec 2014 23:22:44 GMT
@@ -140,67 +149,55 @@ The client is given the URL ``http://www-origin-cache.cdn.com/foo/bar/fun.html``
 
 |arrow| Forward Proxy
 ---------------------
-	A forward proxy acts on behalf of the client. The origin server is mostly unaware of the
proxy, the client requests the proxy to retrieve content from a particular origin server.
All MID caches in a Traffic Control based CDN are forward proxies. In a forward proxy scenario,
the client is explicitly configured to use the the proxy's IP address and port as a forward
proxy. The client always connects to the forward proxy for content. The content provider does
not have to change the URL the [...]
+A forward proxy acts on behalf of the client. The origin server is mostly unaware of the
proxy, the client requests the proxy to retrieve content from a particular origin server.
All MID caches in a Traffic Control based CDN are forward proxies. In a forward proxy scenario,
the client is explicitly configured to use the the proxy's IP address and port as a forward
proxy. The client always connects to the forward proxy for content. The content provider does
not have to change the URL the  [...]
+
+..  seealso:: `ATS documentation on forward proxy <https://docs.trafficserver.apache.org/en/latest/admin/forward-proxy.en.html>`_.
 
-	..  seealso:: `ATS documentation on forward proxy <https://docs.trafficserver.apache.org/en/latest/admin/forward-proxy.en.html>`_.
+Below is an example of the client retrieving the URL ``http://www.origin.com/foo/bar/fun.html``
through a forward proxy:
 
-	Below is an example of the client retrieving the URL ``http://www.origin.com/foo/bar/fun.html``
through a forward proxy:
+1. The client requires configuration to use the proxy, as opposed to the reverse proxy example.
Assume the client configuration is through preferences entries or other to use the proxy IP
address 99.88.77.66 and proxy port 8080.
 
-	1. The client requires configuration to use the proxy, as opposed to the reverse proxy example.
Assume the client configuration is through preferences entries or other to use the proxy IP
address 99.88.77.66 and proxy port 8080.
+2. To retrieve ``http://www.origin.com/foo/bar/fun.html`` URL, the client connects to 99.88.77.66
on port 8080 and sends:
 
-	2. To retrieve ``http://www.origin.com/foo/bar/fun.html`` URL, the client connects to 99.88.77.66
on port 8080 and sends: ::
+	.. code-block:: http
 
 		GET http://www.origin.com/foo/bar/fun.html HTTP/1.1
 		Host: www.origin.com
 
 
-	..  Note:: In this case, the client places the entire URL after ``GET``, including protocol
and hostname (``http://www.origin.com``), but in the reverse proxy and direct-to-origin case
it puts only the path portion of the URL (``/foo/bar/fun.html``) after the ``GET``.
-
-	3. The proxy verifies whether the response for ``http://www-origin-cache.cdn.com/foo/bar/fun.html``
is already in the cache.
-
-	4a. If it is not in the cache:
+..  Note:: In this case, the client places the entire URL after ``GET``, including protocol
and hostname (``http://www.origin.com``), but in the reverse proxy and direct-to-origin case
it puts only the path portion of the URL (``/foo/bar/fun.html``) after the ``GET``.
 
-		1. The proxy uses DNS to obtain the IPv4 address for ``www.origin.com``, connects to it
on port 80, and sends: ::
+3. The proxy verifies whether the response for ``http://www-origin-cache.cdn.com/foo/bar/fun.html``
is already in the cache.
 
+4a. If it is not in the cache:
 
-				GET /foo/bar/fun.html HTTP/1.1
-				Host: www.origin.com
+	1. The proxy uses DNS to obtain the IPv4 address for ``www.origin.com``, connects to it
on port 80, and sends:
 
+		.. code-block:: http
 
-		2. The origin server responds with the headers and content as shown below: ::
+			GET /foo/bar/fun.html HTTP/1.1
+			Host: www.origin.com
 
 
-				HTTP/1.1 200 OK
-				Date: Sun, 14 Dec 2014 23:22:44 GMT
-				Server: Apache/2.2.15 (Red Hat)
-				Last-Modified: Sun, 14 Dec 2014 23:18:51 GMT
-				ETag: "1aa008f-2d-50a3559482cc0"
-				Content-Length: 45
-				Connection: close
-				Content-Type: text/html; charset=UTF-8
+	2. The origin server responds with the headers and content as shown below:
 
-				<!DOCTYPE html><html><body>This is a fun file</body></html>
+		.. code-block:: http
 
+			HTTP/1.1 200 OK
+			Date: Sun, 14 Dec 2014 23:22:44 GMT
+			Server: Apache/2.2.15 (Red Hat)
+			Last-Modified: Sun, 14 Dec 2014 23:18:51 GMT
+			ETag: "1aa008f-2d-50a3559482cc0"
+			Content-Length: 45
+			Connection: close
+			Content-Type: text/html; charset=UTF-8
 
-		3. The proxy sends this on to the client adding a ``Via:`` header (and maybe others): ::
-
-				HTTP/1.1 200 OK
-				Date: Sun, 14 Dec 2014 23:22:44 GMT
-				Last-Modified: Sun, 14 Dec 2014 23:18:51 GMT
-				ETag: "1aa008f-2d-50a3559482cc0"
-				Content-Length: 45
-				Connection: close
-				Content-Type: text/html; charset=UTF-8
-				Age: 0
-				Via: http/1.1 cache01.cdn.kabletown.net (ApacheTrafficServer/4.2.1 [uScSsSfUpSeN:t cCSi
p sS])
-				Server: ATS/4.2.1
-
-				<!DOCTYPE html><html><body>This is a fun file</body></html>
+			<!DOCTYPE html><html><body>This is a fun file</body></html>
 
 
-	4b. If it *is* in the cache:
+	3. The proxy sends this on to the client adding a ``Via:`` header (and maybe others):
 
-		The proxy responds to the client with the previously retrieved result: ::
+		.. code-block:: http
 
 			HTTP/1.1 200 OK
 			Date: Sun, 14 Dec 2014 23:22:44 GMT
@@ -209,8 +206,28 @@ The client is given the URL ``http://www-origin-cache.cdn.com/foo/bar/fun.html``
 			Content-Length: 45
 			Connection: close
 			Content-Type: text/html; charset=UTF-8
-			Age: 99711
+			Age: 0
 			Via: http/1.1 cache01.cdn.kabletown.net (ApacheTrafficServer/4.2.1 [uScSsSfUpSeN:t cCSi
p sS])
 			Server: ATS/4.2.1
 
 			<!DOCTYPE html><html><body>This is a fun file</body></html>
+
+
+4b. If it *is* in the cache:
+
+	The proxy responds to the client with the previously retrieved result:
+
+	.. code-block:: http
+
+		HTTP/1.1 200 OK
+		Date: Sun, 14 Dec 2014 23:22:44 GMT
+		Last-Modified: Sun, 14 Dec 2014 23:18:51 GMT
+		ETag: "1aa008f-2d-50a3559482cc0"
+		Content-Length: 45
+		Connection: close
+		Content-Type: text/html; charset=UTF-8
+		Age: 99711
+		Via: http/1.1 cache01.cdn.kabletown.net (ApacheTrafficServer/4.2.1 [uScSsSfUpSeN:t cCSi
p sS])
+		Server: ATS/4.2.1
+
+		<!DOCTYPE html><html><body>This is a fun file</body></html>
diff --git a/docs/source/basics/http_11.rst b/docs/source/basics/http_11.rst
index d550f7b..9283248 100644
--- a/docs/source/basics/http_11.rst
+++ b/docs/source/basics/http_11.rst
@@ -17,11 +17,11 @@
 	http/1.1
 	HTTP
 
-HTTP 1.1
+HTTP/1.1
 ========
-For a comprehensive look at Traffic Control, it is important to understand basic HTTP 1.1
protocol operations and how caches function. The example below illustrates the fulfillment
of an HTTP 1.1 request in a situation without CDN or proxy, followed by viewing the changes
after inserting different types of (caching) proxies. Several of the examples below are simplified
for clarification of the essentials.
+For a comprehensive look at Traffic Control, it is important to understand basic HTTP/1.1
protocol operations and how caches function. The example below illustrates the fulfillment
of an HTTP/1.1 request in a situation without CDN or proxy, followed by viewing the changes
after inserting different types of (caching) proxies. Several of the examples below are simplified
for clarification of the essentials.
 
-For complete details on HTTP 1.1 see `RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1
<https://www.ietf.org/rfc/rfc2616.txt>`_.
+For complete details on HTTP/1.1 see `RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1
<https://www.ietf.org/rfc/rfc2616.txt>`_.
 
 Below are the steps of a client retrieving the URL ``http://www.origin.com/foo/bar/fun.html``
using HTTP/1.1 without proxies:
 
@@ -31,18 +31,22 @@ Below are the steps of a client retrieving the URL ``http://www.origin.com/foo/b
 
 	.. Note:: While longer DNS TTLs of a day (86400 seconds) or more are quite common in other
use cases, in CDN use cases DNS TTLs are often below a minute.
 
-3. The client opens a TCP connection from a random port locally to port 80 (the HTTP default)
on 44.33.22.11, and sends this (showing the minimum HTTP 1.1 request, typically there are
additional headers): ::
+3. The client opens a TCP connection from a random port locally to port 80 (the HTTP default)
on 44.33.22.11, and sends this (showing the minimum HTTP 1.1 request, typically there are
additional headers):
 
-	GET /foo/bar/fun.html HTTP/1.1
-	Host: www.origin.com
+	.. code-block:: http
 
-4. The server at ``www.origin.com`` looks up the Host: header to match that to a configuration
section, usually referred to as a virtual host section. If the Host: header and configuration
section match, the search continues for the content of the path ``/foo/bar/fun.html``, in
the example, this is a file that contains ``<html><body>This is a fun file</body></html>``,
so the server responds with the following: ::
+		GET /foo/bar/fun.html HTTP/1.1
+		Host: www.origin.com
 
-	HTTP/1.1 200 OK
-	Content-Type: text/html; charset=UTF-8
-	Content-Length: 45
+4. The server at ``www.origin.com`` looks up the Host: header to match that to a configuration
section, usually referred to as a virtual host section. If the Host: header and configuration
section match, the search continues for the content of the path ``/foo/bar/fun.html``, in
the example, this is a file that contains ``<!DOCTYPE html><html><body>This
is a fun file</body></html>``, so the server responds with the following:
 
-	<!DOCTYPE html><html><body>This is a fun file</body></html>
+	.. code-block:: http
+
+		HTTP/1.1 200 OK
+		Content-Type: text/html; charset=UTF-8
+		Content-Length: 45
+
+		<!DOCTYPE html><html><body>This is a fun file</body></html>
 
 
  At this point, HTTP transaction is complete.
diff --git a/docs/source/overview/traffic_monitor.rst b/docs/source/overview/traffic_monitor.rst
index e816ba3..f12ec7b 100644
--- a/docs/source/overview/traffic_monitor.rst
+++ b/docs/source/overview/traffic_monitor.rst
@@ -33,18 +33,18 @@ Traffic Monitor provides a view into CDN health using several RESTful
JSON endpo
 
 |arrow| Cache Monitoring
 -------------------------
-	Traffic Monitor polls all caches configured with a status of ``REPORTED`` or ``ADMIN_DOWN``
at an interval specified as a configuration parameter in Traffic Ops. If the cache is set
to ``ADMIN_DOWN`` it is marked as unavailable but still polled for availability and statistics.
If the cache is explicitly configured with a status of ``ONLINE`` or ``OFFLINE``, it is not
polled by Traffic Monitor and presented to Traffic Router as configured, regardless of actual
availability.
+Traffic Monitor polls all caches configured with a status of ``REPORTED`` or ``ADMIN_DOWN``
at an interval specified as a configuration parameter in Traffic Ops. If the cache is set
to ``ADMIN_DOWN`` it is marked as unavailable but still polled for availability and statistics.
If the cache is explicitly configured with a status of ``ONLINE`` or ``OFFLINE``, it is not
polled by Traffic Monitor and presented to Traffic Router as configured, regardless of actual
availability.
 
-	Traffic Monitor makes HTTP requests at regular intervals to a special URL on each EDGE cache
and consumes the JSON output. The special URL is a plugin running on the Apache Traffic Server
(ATS) caches called astats, which is restricted to Traffic Monitor only. The astats plugin
provides insight into application and system performance, such as:
+Traffic Monitor makes HTTP requests at regular intervals to a special URL on each EDGE cache
and consumes the JSON output. The special URL is a plugin running on the Apache Traffic Server
(ATS) caches called astats, which is restricted to Traffic Monitor only. The astats plugin
provides insight into application and system performance, such as:
 
-	- Throughput (e.g. bytes in, bytes out, etc).
-	- Transactions (e.g. number of 2xx, 3xx, 4xx responses, etc).
-	- Connections (e.g. from clients, to parents, origins, etc).
-	- Cache performance (e.g.: hits, misses, refreshes, etc).
-	- Storage performance (e.g.: writes, reads, frags, directories, etc).
-	- System performance (e.g: load average, network interface throughput, etc).
+- Throughput (e.g. bytes in, bytes out, etc).
+- Transactions (e.g. number of 2xx, 3xx, 4xx responses, etc).
+- Connections (e.g. from clients, to parents, origins, etc).
+- Cache performance (e.g.: hits, misses, refreshes, etc).
+- Storage performance (e.g.: writes, reads, frags, directories, etc).
+- System performance (e.g: load average, network interface throughput, etc).
 
-	Many of the application level statistics are available at the global or aggregate level,
some at the Delivery Service (remap rule) level. Traffic Monitor uses the system level performance
to determine the overall health of the cache by evaluating network throughput and load against
values configured in Traffic Ops. Traffic Monitor also uses throughput and transaction statistics
at the remap rule level to determine Delivery Service health.
+Many of the application-level statistics are available at the global or aggregate level,
some at the Delivery Service (remap rule) level. Traffic Monitor uses the system level performance
to determine the overall health of the cache by evaluating network throughput and load against
values configured in Traffic Ops. Traffic Monitor also uses throughput and transaction statistics
at the remap rule level to determine Delivery Service health.
 
 If astats is unavailable due to a network related issue or the system statistics have exceeded
the configured thresholds, Traffic Monitor will mark the cache as unavailable. If the delivery
service statistics exceed the configured thresholds, the delivery service is marked as unavailable,
and Traffic Router will start sending clients to the overflow destinations for that delivery
service, but the cache remains available to serve other content,
 
@@ -54,13 +54,13 @@ If astats is unavailable due to a network related issue or the system
statistics
 
 |arrow| Health Protocol
 -----------------------
-	Redundant Traffic Monitor servers operate independently from each other but take the state
of other Traffic Monitors into account when asked for health state information. In the above
overview of cache monitoring, the behavior of Traffic Monitor pertains only to how an individual
instance detects and handles failures. The Health Protocol adds another dimension to the health
state of the CDN by merging the states of all Traffic Monitors into one, and then taking the
*optimistic* approach [...]
+Redundant Traffic Monitor servers operate independently from each other but take the state
of other Traffic Monitors into account when asked for health state information. In the above
overview of cache monitoring, the behavior of Traffic Monitor pertains only to how an individual
instance detects and handles failures. The Health Protocol adds another dimension to the health
state of the CDN by merging the states of all Traffic Monitors into one, and then taking the
*optimistic* approach  [...]
 
-	Upon startup or configuration change in Traffic Ops, in addition to caches, Traffic Monitor
begins polling its peer Traffic Monitors whose state is set to ``ONLINE``. Each ``ONLINE``
Traffic Monitor polls all of its peers at a configurable interval and saves the peer's state
for later use. When polling its peers, Traffic Monitor asks for the raw health state from
each respective peer, which is strictly that instance's view of the CDN's health. When any
``ONLINE`` Traffic Monitor is aske [...]
+Upon startup or configuration change in Traffic Ops, in addition to caches, Traffic Monitor
begins polling its peer Traffic Monitors whose state is set to ``ONLINE``. Each ``ONLINE``
Traffic Monitor polls all of its peers at a configurable interval and saves the peer's state
for later use. When polling its peers, Traffic Monitor asks for the raw health state from
each respective peer, which is strictly that instance's view of the CDN's health. When any
``ONLINE`` Traffic Monitor is asked [...]
 
-	In operation of the health protocol, Traffic Monitor takes all health states from all peers,
including the locally known health state, and serves an optimistic outlook to the requesting
client. This means that, for example, if three of the four Traffic Monitors see a given cache
or Delivery Service as exceeding its thresholds and unavailable, it is still considered available.
Only if all Traffic Monitors agree that the given object is unavailable is that state propagated
to upstream com [...]
+In operation of the health protocol, Traffic Monitor takes all health states from all peers,
including the locally known health state, and serves an optimistic outlook to the requesting
client. This means that, for example, if three of the four Traffic Monitors see a given cache
or Delivery Service as exceeding its thresholds and unavailable, it is still considered available.
Only if all Traffic Monitors agree that the given object is unavailable is that state propagated
to upstream comp [...]
 
-It is not uncommon for a cache to be marked unavailable by Traffic Monitor - in fact, it
is business as usual for many CDNs. A hot video asset may cause a single cache (say cache-03)
to get close to it's interface capacity, the health protocol "kicks in", and Traffic Monitor
marks cache-03 as unavailable. New clients want to see the same asset, and now, Traffic Router
will send these customers to another cache (say cache-01) in the same cachegroup. The load
is now shared between cache-01 [...]
+It is not uncommon for a cache to be marked unavailable by Traffic Monitor - in fact, it
is business as usual for many CDNs. Should a widely-requested video asset cause a single cache
to get close to its interface capacity, the Health Protocol will "kicks in", and Traffic Monitor
marks cache-03 as unavailable. New clients want to see the same asset, and now, Traffic Router
will send these customers to another cache (say cache-01) in the same Cache Group. The load
is now shared between ca [...]
 
 It is less common for a delivery service to be marked unavailable by Traffic Monitor, the
delivery service thresholds are usually used for overflow situations at extreme peaks to protect
other delivery services in the CDN from getting impacted.
 
diff --git a/docs/source/overview/traffic_ops.rst b/docs/source/overview/traffic_ops.rst
index f3766b5..4310cce 100644
--- a/docs/source/overview/traffic_ops.rst
+++ b/docs/source/overview/traffic_ops.rst
@@ -31,9 +31,15 @@ Traffic Ops is in the process of migrating from Perl to Go, and currently
runs a
 
 |arrow| Traffic Ops Extension
 -----------------------------
-	Traffic Ops Extensions are a way to enhance the basic functionality of Traffic Ops in a
custom manner. There are three types of extensions:
+Traffic Ops Extensions are a way to enhance the basic functionality of Traffic Ops in a custom
manner. There are two types of extensions:
 
-	* Check Extensions - Allows you to add custom checks to the "Health->Server Checks" view.
-	* Configuration Extension - Allows you to add custom configuration file generators.
-	* Data source Extensions - Allows you to add data sources for the graph views and usage
APIs.
+Check Extension
+	Allows you to add custom checks to the 'Monitor' -> 'Cache Checks' view.
 
+Data source Extensions
+	Allows you to add data sources for the graph views and usage APIs.
+
+
+.. These are listed as "in beta" as far back as TO 1.0, sooo
+.. Configuration Extension
+.. 	Allows you to add custom configuration file generators.
diff --git a/docs/source/overview/traffic_router.rst b/docs/source/overview/traffic_router.rst
index 60398a3..d466e8a 100644
--- a/docs/source/overview/traffic_router.rst
+++ b/docs/source/overview/traffic_router.rst
@@ -69,12 +69,16 @@ Traffic Router is inserted into the HTTP retrieval process by making it
DNS auth
 
 |arrow| HTTP Content Routing
 ----------------------------
-	For an HTTP Delivery Service the client might receive a URL such as ``http://bar.dsname.cdn.com/fun/example.html``.
The LDNS server resolves this ``bar.dsname.cdn.com`` to an IP address, but in this case Traffic
Router returns its own IP address. The client opens a connection to port 80 on the Traffic
Router's IP address, and sends: ::
+	For an HTTP Delivery Service the client might receive a URL such as ``http://bar.dsname.cdn.com/fun/example.html``.
The LDNS server resolves this ``bar.dsname.cdn.com`` to an IP address, but in this case Traffic
Router returns its own IP address. The client opens a connection to port 80 on the Traffic
Router's IP address, and sends:
+
+	.. code-block:: http
 
 		GET /fun/example.html HTTP/1.1
 		Host: bar.dsname.cdn.com
 
-	Traffic Router uses an HTTP 302 to redirect the client to the best cache. For example: ::
+	Traffic Router uses an HTTP 302 to redirect the client to the best cache. For example:
+
+	.. code-block:: http
 
 		HTTP/1.1 302 Moved Temporarily
 		Server: Apache-Coyote/1.1


Mime
View raw message