trafficserver-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jpe...@apache.org
Subject [31/51] trafficserver git commit: Documentation reorganization
Date Tue, 03 Nov 2015 06:10:07 GMT
http://git-wip-us.apache.org/repos/asf/trafficserver/blob/ce162a6d/doc/admin/reverse-proxy-http-redirects.en.rst
----------------------------------------------------------------------
diff --git a/doc/admin/reverse-proxy-http-redirects.en.rst b/doc/admin/reverse-proxy-http-redirects.en.rst
deleted file mode 100644
index 65e6742..0000000
--- a/doc/admin/reverse-proxy-http-redirects.en.rst
+++ /dev/null
@@ -1,331 +0,0 @@
-.. _reverse-proxy-and-http-redirects:
-
-Reverse Proxy and HTTP Redirects
-********************************
-
-.. Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-   distributed with this work for additional information
-   regarding copyright ownership.  The ASF licenses this file
-   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
-   KIND, either express or implied.  See the License for the
-   specific language governing permissions and limitations
-   under the License.
-
-Reverse Proxy and HTTP Redirects
-================================
-
-As a reverse proxy cache, Traffic Server serves requests on behalf of
-origin servers. Traffic Server is configured in such a way that it
-appears to clients like a normal origin server.
-
-.. toctree::
-   :maxdepth: 2
-
-Understanding Reverse Proxy Caching
-===================================
-
-With *forward proxy caching*, Traffic Server handles web requests to origin
-servers on behalf of the clients requesting the content. *Reverse proxy
-caching* (also known as *server acceleration*) is different because Traffic
-Server acts as a proxy cache on behalf of the origin servers that store the
-content. Traffic Server is configured to behave outwardly as origin server
-which the client is trying to connect to. In a typical scenario the advertised
-hostname of the origin server resolves to Traffic Server, which serves client
-requests directly, fetching content from the true origin server when necessary.
-
-Reverse Proxy Solutions
------------------------
-
-There are many ways to use Traffic Server as a reverse proxy. Below are
-a few example scenarios.
-
--  Offload heavily-used origin servers.
-
--  Deliver content efficiently in geographically distant areas.
-
--  Provide security for origin servers that contain sensitive information.
-
-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
-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
-origin servers, as shown in the figure below.
-
-.. figure:: ../static/images/admin/revproxy.jpg
-   :align: center
-   :alt: Traffic Server as reverse proxy for a pair of origin servers
-
-   Traffic Server as reverse proxy for a pair of origin servers
-
-Delivering Content in Geographically-Dispersed Areas
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Traffic Server can be used in reverse proxy mode to accelerate origin
-servers that provide content to areas not located within close
-geographical proximity. Caches are typically easier to manage and are
-more cost-effective than replicating data. For example, Traffic Server
-can be used as a mirror site on the far side of a trans-Atlantic link to
-serve users without having to fetch the request and content across
-expensive, or higher latency, international connections. Unlike replication,
-for which hardware must be configured to replicate all data and to handle peak
-capacity, Traffic Server dynamically adjusts to optimally use the
-serving and storing capacity of the hardware. Traffic Server is also
-designed to keep content fresh automatically, thereby eliminating the
-complexity of updating remote origin servers.
-
-Providing Security for an Origin Server
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Traffic Server can be used in reverse proxy mode to provide security for
-an origin server. If an origin server contains sensitive information
-that you want to keep secure inside your firewall, then you can use a
-Traffic Server outside the firewall as a reverse proxy for that origin
-server. When outside clients try to access the origin server, the
-requests instead go to Traffic Server. If the desired content is not
-sensitive, then it can be served from the cache. If the content is
-sensitive and not cacheable, then Traffic Server obtains the content
-from the origin server (the firewall allows only Traffic Server access
-to the origin server). The sensitive content resides on the origin
-server, safely inside the firewall.
-
-How Does Reverse Proxy Work?
-----------------------------
-
-When a browser makes a request, it normally sends that request directly
-to the origin server. When Traffic Server is in reverse proxy mode, it
-intercepts the request before it reaches the origin server. Typically,
-this is done by setting up the DNS entry for the origin server (i.e.,
-the origin server's advertised hostname) so it resolves to the Traffic
-Server IP address. When Traffic Server is configured as the origin
-server, the browser connects to Traffic Server rather than the origin
-server. For additional information, see `HTTP Reverse Proxy`_.
-
-.. note::
-
-    To avoid a DNS conflict, the origin server’s hostname and its advertised
-    hostname must not be the same.
-
-HTTP Reverse Proxy
-==================
-
-In reverse proxy mode, Traffic Server serves HTTP requests on behalf of
-a web server. The figure below illustrates how Traffic Server in reverse
-proxy mode serves an HTTP request from a client browser.
-
-.. figure:: ../static/images/admin/httprvs.jpg
-   :align: center
-   :alt: HTTP reverse proxy
-
-   HTTP reverse proxy
-
-The figure above demonstrates the following steps:
-
-.. List below should remain manually numbered, as the entries correspond to numbers in the figure above.
-
-1. A client browser sends an HTTP request addressed to a host called
-   ``www.host.com`` on port 80. Traffic Server receives the request
-   because it is acting as the origin server (the origin server’s
-   advertised hostname resolves to Traffic Server).
-
-2. Traffic Server locates a map rule in the :file:`remap.config` file and
-   remaps the request to the specified origin server (``realhost.com``).
-
-3. If the request cannot be served from cache, Traffic Server opens a
-   connection to the origin server (or more likely, uses an existing
-   connection it has pre-established), retrieves the content, and optionally
-   caches it for future use.
-
-4. If the request was a cache hit and the content is still fresh in the cache,
-   or the content is now available through Traffic Server because of step 3,
-   Traffic Server sends the requested object to the client from the cache
-   directly.
-
-.. note::
-
-    Traffic Server, when updating its own cache from the origin server, will
-    simultaneously deliver that content to the client while updating its
-    cache database. The response to the client containing the requested object
-    will begin as soon as Traffic Server has received and processed the full
-    response headers from the origin server.
-
-To configure HTTP reverse proxy, you must perform the following tasks:
-
--  Create mapping rules in the :file:`remap.config` file (refer to `Creating
-   Mapping Rules for HTTP Requests`_). ::
-
-      map http://www.host.com http://realhost.com
-
--  Enable the reverse proxy option (refer to `Enabling HTTP Reverse Proxy`_).
-
-In addition to the tasks above, you can also `Setting Optional HTTP Reverse Proxy Options`_.
-
-Handling Origin Server Redirect Responses
------------------------------------------
-
-Origin servers often send redirect responses back to browsers
-redirecting them to different pages. For example, if an origin server is
-overloaded, then it might redirect browsers to a less loaded server.
-Origin servers also redirect when web pages have moved to different
-locations. When Traffic Server is configured as a reverse proxy, it must
-readdress redirects from origin servers so that browsers are redirected
-to Traffic Server and not to another origin server.
-
-To readdress redirects, Traffic Server uses reverse-map rules. Unless
-you have :ts:cv:`proxy.config.url_remap.pristine_host_hdr` enabled
-(the default) you should generally set up a reverse-map rule for
-each map rule. To create reverse-map rules, refer to `Using Mapping
-Rules for HTTP Requests`_.
-
-Using Mapping Rules for HTTP Requests
--------------------------------------
-
-Traffic Server uses two types of mapping rules for HTTP reverse proxy.
-
-map rule
-~~~~~~~~
-
-A *map rule* translates the URL in client requests into the URL where
-the content is located. When Traffic Server is in reverse proxy mode and
-receives an HTTP client request, it first constructs a complete request
-URL from the relative URL and its headers. Traffic Server then looks for
-a match by comparing the complete request URL with its list of target
-URLs in :file:`remap.config`. For the request URL to match a target URL, the
-following conditions must be true:
-
--  The scheme of both URLs must be the same.
-
--  The host in both URLs must be the same. If the request URL contains
-   an unqualified hostname, then it will never match a target URL with a
-   fully-qualified hostname.
-
--  The ports in both URLs must be the same. If no port is specified in a
-   URL, then the default port for the scheme of the URL is used.
-
--  The path portion of the target URL must match a prefix of the request
-   URL path.
-
-If Traffic Server finds a match, then it translates the request URL into
-the replacement URL listed in the map rule: it sets the host and path of
-the request URL to match the replacement URL. If the URL contains path
-prefixes, then Traffic Server removes the prefix of the path that
-matches the target URL path and substitutes it with the path from the
-replacement URL. If two mappings match a request URL, then Traffic
-Server applies the first mapping listed in :file:`remap.config`.
-
-reverse-map rule
-~~~~~~~~~~~~~~~~
-
-A *reverse-map rule* translates the URL in origin server redirect
-responses to point to Traffic Server so that clients are redirected
-to Traffic Server instead of accessing an origin server directly. For
-example, if there is a directory ``/pub`` on an origin server at
-``www.molasses.com`` and a client sends a request to that origin server
-for ``/pub``, then the origin server might reply with a redirect by
-sending the Header ``Location: http://realhost.com/pub/`` to let the
-client know that it was a directory it had requested, not a document (a
-common use of redirects is to normalize URLs so that clients can
-bookmark documents properly).
-
-Traffic Server uses ``reverse_map`` rules to prevent clients (that
-receive redirects from origin servers) from bypassing Traffic Server and
-directly accessing the origin servers. In many cases the client would be
-hitting a wall because ``realhost.com`` actually does not resolve for
-the client. (E.g.: Because it's running on a port shielded by a
-firewall, or because it's running on a non-routable LAN IP)
-
-Both map and reverse-map rules consist of a *target* (origin) URL and
-a *replacement* (destination) URL. In a *map rule*, the target URL
-points to Traffic Server and the replacement URL specifies where the
-original content is located. In a *reverse-map rule*, the target URL
-specifies where the original content is located and the replacement URL
-points to Traffic Server. Traffic Server stores mapping rules in
-:file:`remap.config` located in the Traffic Server ``config`` directory.
-
-Creating Mapping Rules for HTTP Requests
-----------------------------------------
-
-To create mapping rules:
-
-#. Enter the map and reverse-map rules into :file:`remap.config`.
-
-#. Run the command :option:`traffic_ctl config reload` to apply the configuration changes.
-
-Enabling HTTP Reverse Proxy
----------------------------
-
-To enable HTTP reverse proxy:
-
-#. Edit :ts:cv:`proxy.config.reverse_proxy.enabled` in :file:`records.config`. ::
-
-    CONFIG proxy.config.reverse_proxy.enabled INT 1
-
-#. Run the command :option:`traffic_ctl config reload` to apply the configuration changes.
-
-Setting Optional HTTP Reverse Proxy Options
--------------------------------------------
-
-Traffic Server provides several reverse proxy configuration options in
-:file:`records.config` that enable you to:
-
--  Configure Traffic Server to retain the client host header information
-   in a request during translation.
-   See :ts:cv:`proxy.config.url_remap.pristine_host_hdr`.
-
--  Configure Traffic Server to serve requests only to the origin servers
-   listed in the mapping rules. As a result, requests to origin servers
-   not listed in the mapping rules are not served.
-   See :ts:cv:`proxy.config.url_remap.remap_required`.
-
--  Specify an alternate URL to which incoming requests from older clients ,such
-   as ones that do not provide ``Host`` headers, are directed.
-   See :ts:cv:`proxy.config.header.parse.no_host_url_redirect`.
-
-Run the command :option:`traffic_ctl config reload` to apply any of these configuration
-changes.
-
-Redirecting HTTP Requests
-=========================
-
-You can configure Traffic Server to redirect HTTP requests without
-having to contact any origin servers. For example, if you redirect all
-requests for ``http://www.ultraseek.com`` to
-``http://www.server1.com/products/portal/search/``, then all HTTP
-requests for ``www.ultraseek.com`` go directly to
-``www.server1.com/products/portal/search``.
-
-You can configure Traffic Server to perform permanent or temporary
-redirects. *Permanent redirects* notify the browser of the URL change
-(by returning the HTTP status code ``301``) so that the browser can
-update bookmarks. *Temporary redirects* notify the browser of the URL
-change for the current request only (by returning the HTTP status code
-``307`` ).
-
-To set redirect rules:
-
-#. For each redirect you want to set enter a mapping rule in :file:`remap.config`.
-
-#. Run the command :option:`traffic_ctl config reload` to apply the configuration changes.
-
-Example
--------
-
-The following permanently redirects all HTTP requests for
-``www.server1.com`` to ``www.server2.com``: ::
-
-    redirect http://www.server1.com http://www.server2.com
-
-

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/ce162a6d/doc/admin/security-options.en.rst
----------------------------------------------------------------------
diff --git a/doc/admin/security-options.en.rst b/doc/admin/security-options.en.rst
deleted file mode 100644
index c93854c..0000000
--- a/doc/admin/security-options.en.rst
+++ /dev/null
@@ -1,325 +0,0 @@
-.. _security-options:
-
-Security Options
-****************
-
-.. Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-   distributed with this work for additional information
-   regarding copyright ownership.  The ASF licenses this file
-   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
-   KIND, either express or implied.  See the License for the
-   specific language governing permissions and limitations
-   under the License.
-
-.. _controlling-client-access-to-cache:
-
-Controlling Client Access to the Proxy Cache
-============================================
-
-Traffic Server can be configured to allow only certain clients to use
-the proxy cache.
-
-#. Add a line to :file:`ip_allow.config` for each IP address or
-   range of IP addresses allowed to access Traffic Server.
-
-#. Run the command :option:`traffic_ctl config reload` to apply the configuration
-   changes.
-
-.. _configuring-dns-server-selection-split-dns:
-
-Configuring DNS Server Selection (Split DNS)
-============================================
-
-The *Split DNS* option enables you to configure Traffic Server to use
-multiple DNS servers, as dictated by your security requirements. For
-example, you might configure Traffic Server to use one set of DNS
-servers to resolve hostnames on your internal network, while allowing
-DNS servers outside the firewall to resolve hosts on the Internet. This
-maintains the security of your intranet, while continuing to provide
-direct access to sites outside your organization.
-
-To configure Split DNS:
-
-#. Specify the rules for performing DNS server selection based on the
-   destination domain, the destination host, or a URL regular expression.
-   These rules are located in :file:`splitdns.config`.
-
-#. Enable the *Split DNS* option by adjusting :ts:cv:`proxy.config.dns.splitDNS.enabled`
-   in :file:`records.config`. ::
-
-        CONFIG proxy.config.dns.splitDNS.enabled INT 1
-
-#. Run the command :option:`traffic_ctl config reload` to apply the configuration changes.
-
-.. _configuring-ssl-termination:
-
-Using SSL Termination
-=====================
-
-The Traffic Server *SSL termination* option enables you to secure
-connections in reverse proxy mode between a client and a Traffic Server
-and/or Traffic Server and an origin server.
-
-The following sections describe how to enable and configure the SSL
-termination option.
-
--  Enable and configure SSL termination for client/Traffic Server
-   connections: :ref:`admin-client-and-traffic-server-connections`
-
--  Enable and configure SSL termination for Traffic Server/origin server
-   connections: :ref:`admin-traffic-server-and-origin-server-connections`
-
-.. _client-and-traffic-server-connections:
-
-Client and Traffic Server Connections
--------------------------------------
-
-.. XXX sanity check/second opinions on example paths used for certs/keys below
-
-The figure below illustrates communication between a client and Traffic
-Server (and between Traffic Server and an origin server) when the SSL
-termination option is enabled and configured for Client/Traffic
-Server connections only.
-
-.. figure:: ../static/images/admin/ssl_c.jpg
-   :align: center
-   :alt: Client and Traffic Server communication using SSL termination
-
-   Client and Traffic Server communication using SSL termination
-
-.. Manual list numbering below corresponds to figure markings above.
-
-The figure above depicts the following:
-
-1. The client sends an HTTPS request for content. Traffic Server receives the
-   request and performs the SSL handshake to authenticate the client (depending
-   on the authentication options configured) and determine the encryption
-   method that will be used. If the client is allowed access, then Traffic
-   Server checks its cache for the requested content.
-
-2. If the request is a cache hit and the content is fresh, then Traffic Server
-   encrypts the content and sends it to the client. The client decrypts the
-   content (using the method determined during the handshake) and displays it.
-
-3. If the request is a cache miss or cached content is stale, then Traffic
-   Server communicates with the origin server via HTTP and obtains a plain text
-   version of the content. Traffic Server saves the plain text version of the
-   content in its cache, encrypts the content, and sends it to the client. The
-   client decrypts and displays the content.
-
-To configure Traffic Server to use the SSL termination option for
-Client/Traffic Server connections, you must do the following:
-
-#. Obtain and install an SSL server certificate from a recognized
-   certificate authority. The SSL server certificate contains
-   information that enables the client to authenticate Traffic Server
-   and exchange encryption keys.
-
-#. Set the port number used for SSL communication using
-   :ts:cv:`proxy.config.http.server_ports` in :file:`records.config`.
-
-#. Set the appropriate base path for your SSL certificates and private keys
-   in :file:`records.config`. ::
-
-        CONFIG proxy.config.ssl.server.cert.path STRING "/opt/ts/etc/ssl/certs/"
-        CONFIG proxy.config.ssl.server.private_key.path STRING "/opt/ts/etc/ssl/keys/"
-
-#. Add an entry to :file:`ssl_multicert.config` for each certificate and key
-   which your Traffic Server system will be using to terminate SSL connections
-   with clients. ::
-
-        ip_dest=1.2.3.4 ssl_cert_name=example.com.pem
-        ip_dest=* ssl_cert_name=default.pem
-
-#. *Optional*: Configure the use of client certificates using the variable
-   :ts:cv:`proxy.config.ssl.client.certification_level` in :file:`records.config`.
-   If you configure Traffic Server to require client certificates, then Traffic
-   Server verifies the client certificate during the SSL handshake that
-   authenticates the client. If you configure Traffic Server to not require
-   client certificates, or if you configure certificates to be optional and the
-   connecting client does not present one, then access to Traffic Server is
-   managed through other Traffic Server options that have been set (such as
-   rules in :file:`ip_allow.config`). ::
-
-        CONFIG proxy.config.ssl.client.certification_level INT 0
-
-   This variable permits one of the following values to be set:
-
-   ===== =======================================================================
-   Value Description
-   ===== =======================================================================
-   ``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.
-   ===== =======================================================================
-
-#. *Optional*: Configure the use of Certification Authorities (CAs). CAs add
-   security by verifying the identity of the person requesting a certificate.
-   The list of acceptable CA signers is configured with
-   :ts:cv:`proxy.config.ssl.CA.cert.path` in :file:`records.config`. ::
-
-        CONFIG proxy.config.ssl.CA.cert.path STRING "/opt/CA/certs/private-ca.pem"
-
-#. Run the command :option:`traffic_ctl server restart` to restart Traffic Server on the
-   local node or :option:`traffic_ctl cluster restart` to restart Traffic Server on all
-   the nodes in a cluster.
-
-.. _traffic-server-and-origin-server-connections:
-
-Traffic Server and Origin Server Connections
---------------------------------------------
-
-.. XXX sanity check/second opinions on example paths used for certs/keys below
-
-The figure below illustrates communication between Traffic Server and an
-origin server when the SSL termination option is enabled for Traffic
-Server/origin server connections.
-
-.. figure:: ../static/images/admin/ssl_os.jpg
-   :align: center
-   :alt: Traffic Server and origin server communication using SSL termination
-
-   Traffic Server and origin server communication using SSL termination
-
-.. Manual list numbering below corresponds to figure markings above.
-
-The figure above depicts the following:
-
-1. If a client request is a cache miss or is stale, then Traffic Server sends
-   an HTTPS request for the content to the origin server. The origin server
-   receives the request and performs the SSL handshake to authenticate Traffic
-   Server and determine the encryption method to be used.
-
-2. If Traffic Server is allowed access, then the origin server encrypts the
-   content and sends it to Traffic Server, where it is decrypted (using the
-   method determined during the handshake). A plain text version of the content
-   is saved in the cache, if Traffic Server deems the content cacheable.
-
-3. If SSL termination is enabled for Client/Traffic Server connections, then
-   Traffic Server re-encrypts the content and sends it to the client via HTTPS,
-   where it is decrypted and displayed. If SSL termination is not enabled for
-   Client/Traffic Server connections, then Traffic Server sends the plain text
-   version of the content to the client via HTTP.
-
-To configure Traffic Server to use the SSL termination option for Traffic Server
-and origin server connections, you must do the following:
-
-#. Ensure first that your origin server responds properly to SSL requests, and
-   configure it for client certificate validation if you intend to use that as
-   part of your access control scheme.
-
-   Refer to your origin server's documentation for details. If your origin
-   server is another Traffic Server system, then you may follow the steps
-   outlined in `Client and Traffic Server Connections`_ for configuring the
-   origin server to validate client certificates.
-
-#. *Optional*: Obtain and install an SSL client certificate from a recognized
-   certificate authority, if your origin server requires client certificate
-   validation for access control. Your client certificate must be signed by a
-   Certificate Authority recognized by your origin server.
-
-   If you are using a client certificate, you must add its location to
-   :file:`records.config` in the setting :ts:cv:`proxy.config.ssl.client.cert.path`
-   and :ts:cv:`proxy.config.ssl.client.cert.filename`. ::
-
-        CONFIG proxy.config.ssl.client.cert.path STRING "/opt/ts/etc/ssl/certs/"
-        CONFIG proxy.config.ssl.client.cert.filename STRING "client.pem"
-
-   You must also provide the paths to the private key for this certificate,
-   unless the key is contained within the same file as the certificate, using
-   :ts:cv:`proxy.config.ssl.client.private_key.path` and
-   :ts:cv:`proxy.config.ssl.client.private_key.filename`. ::
-
-        CONFIG proxy.config.ssl.client.private_key.path STRING "/opt/ts/etc/ssl/keys/"
-        CONFIG proxy.config.ssl.client.private_key.filename STRING "client.pem"
-
-#. Enable or disable, per your security policy, server SSL certificate
-   verification using :ts:cv:`proxy.config.ssl.client.verify.server` in
-   :file:`records.config`. ::
-
-        CONFIG proxy.config.ssl.client.verify.server INT 1
-
-#. Add the collection of authorized Certificate Authorities to the Traffic
-   Server configuration in :file:`records.config` using the settings
-   :ts:cv:`proxy.config.ssl.client.CA.cert.path` and
-   :ts:cv:`proxy.config.ssl.client.CA.cert.filename`. ::
-
-        CONFIG proxy.config.ssl.client.CA.cert.path STRING "/opt/ts/etc/ssl/certs/"
-        CONFIG proxy.config.ssl.client.CA.cert.filename STRING "CAs.pem"
-
-#. Run the command :option:`traffic_ctl server restart` to restart Traffic Server on the
-   local node or :option:`traffic_ctl cluster restart` to restart Traffic Server on all
-   the nodes in a cluster.
-
-Rotating TLS Session Ticket Keys
-============================================
-
-TLS sessions can be resumed through session tickets which are encrypted with
-a session ticket key and stored on clients. For better security, the ticket keys
-can be rotated periodically, say, every 24 hours. The ticket keys are stored in
-a ticket key file as a reverse queue in 48-byte chunks.
-
-#. Generate a new ticket key and push it to the beginning of the ticket key file.
-
-#. *Optional*: Delete the last ticket key from the ticket key file.
-
-#. Touch :file:`ssl_multicert.config` to indicate that the SSL configuration is stale.
-
-#. Run the command :option:`traffic_ctl config reload` to apply the new ticket key.
-
-OCSP Stapling
-============================================
-
-OCSP Stapling is an alternative approach to checking the revocation
-status of an SSL certificate using the Online Certificate Status
-Protocol.
-
-Under the original OCSP implementation, clients requested a
-certificate's revocation status directly from the Certificate
-Authority (CA) that issued the certificate.  This could cause
-significant load on the CA servers since they were required to
-provide a response to every client of a given certificate in real
-time.
-
-Enabling OCSP Stapling instructs Traffic Server to retrieve and cache the
-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
-Authority Information Access field of the signed certificate. For example::
-
-    Authority Information Access:
-                OCSP - URI:http://ocsp.digicert.com
-                CA Issuers - URI:http://cacerts.digicert.com/DigiCertSHA2SecureServerCA.crt
-
-Support for OCSP Stapling can be tested using the -status option of the OpenSSL client::
-
-    $ openssl s_client -connect mozillalabs.com:443 -status
-    ...
-    ======================================
-    OCSP Response Data:
-        OCSP Response Status: successful (0x0)
-        Response Type: Basic OCSP Response
-        Version: 1 (0x0)
-    ...
-
-Details of the OCSP Stapling TLS extension can be found in :rfc:`6961`.
-
-To configure Traffic Server to use OCSP Stapling, edit the following variables
-in :file:`records.config` file:
-
-* :ts:cv:`proxy.config.ssl.ocsp.enabled`
-* :ts:cv:`proxy.config.ssl.ocsp.cache_timeout`
-* :ts:cv:`proxy.config.ssl.ocsp.request_timeout`
-* :ts:cv:`proxy.config.ssl.ocsp.update_period`
-

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/ce162a6d/doc/admin/session-protocol.en.rst
----------------------------------------------------------------------
diff --git a/doc/admin/session-protocol.en.rst b/doc/admin/session-protocol.en.rst
deleted file mode 100644
index 20a3bf1..0000000
--- a/doc/admin/session-protocol.en.rst
+++ /dev/null
@@ -1,59 +0,0 @@
-.. _session-protocol:
-
-Session Protocol
-****************
-
-.. Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-   distributed with this work for additional information
-   regarding copyright ownership.  The ASF licenses this file
-   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
-   KIND, either express or implied.  See the License for the
-   specific language governing permissions and limitations
-   under the License.
-
-Traffic Server supports some session level protocols in place of, or on top of
-HTTP. These can be provided by a plugin (see :ref:`new-protocol-plugins`) or
-be one that is supported directly by Traffic Server. The
-`SPDY <http://www.chromium.org/spdy>`_ protocol is the only one currently
-supported, but it is planned to support HTTP 2 when that is finalized.
-
-Session protocols are specified by explicit names, based on the
-`NPN <https://technotes.googlecode.com/git/nextprotoneg.html>`_ names. The
-core supported names are:
-
-*  ``http/0.9``
-*  ``http/1.0``
-*  ``http/1.1``
-*  ``http/2``
-*  ``spdy/1``
-*  ``spdy/2``
-*  ``spdy/3``
-*  ``spdy/3.1``
-
-The ``http/2`` value is not currently functional, but is included for future
-use. Both ``spdy/1`` and ``spdy/2`` are obsolete, but are include for
-completeness.
-
-The session protocols supported on a proxy port are a subset of these values.
-For convenience some pseudo-values are defined in terms of these fundamental
-protocols:
-
-*  ``http`` means ``http/0.9``, ``http/1.0``, and ``http/1.1``
-*  ``spdy`` means ``spdy/3`` and ``spdy/3.1``.
-*  ``http2`` means ``http/2``
-
-Each proxy port can be configured in :ts:cv:`proxy.config.http.server_ports`
-to support a subset of these session protocols. For TLS enabled connections this
-configuration controls which protocols are offered by NPN. Protocol sniffing is
-use for non-TLS proxy ports to determine which protocol is being used by the
-client. If the detected protocol is not supported for that proxy port the
-connection is dropped.

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/ce162a6d/doc/admin/traffic-server-error-messages.en.rst
----------------------------------------------------------------------
diff --git a/doc/admin/traffic-server-error-messages.en.rst b/doc/admin/traffic-server-error-messages.en.rst
deleted file mode 100644
index b15a491..0000000
--- a/doc/admin/traffic-server-error-messages.en.rst
+++ /dev/null
@@ -1,359 +0,0 @@
-.. _traffic-server-error-messages:
-
-Error Messages
-**************
-
-.. Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-   distributed with this work for additional information
-   regarding copyright ownership.  The ASF licenses this file
-   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
-   KIND, either express or implied.  See the License for the
-   specific language governing permissions and limitations
-   under the License.
-
-.. toctree::
-   :maxdepth: 2
-
-Traffic Server Error Messages
-=============================
-
-The following table lists messages that can appear in system log files.
-This list is not exhaustive; it simply describes common warning messages
-that can occur and which might require your attention.
-
-Traffic Server Process Fatal
-============================
-
-``Accept port is not between 1 and 65535. Please check configuration``
-   The port specified in :file:`records.config` that accepts
-   incoming HTTP requests is not valid.
-
-``Self loop is detected in parent proxy configuration``
-   The name and port of the parent proxy match that of Traffic Server.
-   This creates a loop when Traffic Server attempts to send the request
-   to the parent proxy.
-
-Traffic Server Warnings
------------------------
-
-``<Logfile> error: error_number``
-   Generic logging error.
-
-``Bad cluster major version range <version1-version2> for node <IP address> connect failed``
-   Incompatible software versions causing a problem.
-
-``Connect by disallowed client <IP address>, closing``
-   The specified client is not allowed to connect to Traffic Server;
-   the client IP address is not listed in the ``ip_allow.config`` file.
-
-``Could not rename log <filename> to <rolled filename>``
-   System error when renaming log file during roll.
-
-``Did <this amount> of backup; still to do <remaining amount>``
-   Congestion is approaching.
-
-``Different clustering minor versions <version1, version2> for node <IP address> continuing``
-   Incompatible software versions are causing a problem.
-
-``Log format symbol <symbol name> not found``
-   Custom log format references a field symbol that does not exist.
-   Refer to :ref:`admin-event-logging-formats`.
-
-``Missing field for field marker``
-   Error reading a log buffer.
-
-``Unable to open log file <filename>, errno=<error number>``
-   Cannot open the log file.
-
-``Error accessing disk <disk name>``
-   Traffic Server might have a cache read problem. You might need to
-   replace the disk.
-
-``Too many errors accessing disk <disk name>: declaring disk bad``
-   Traffic Server is not using the cache disk because it encountered
-   too many errors. The disk might be corrupt and might have to be
-   replaced.
-
-``No cache disks specified in storage.config file: cache disabled``
-   The Traffic Server :file:`storage.config` file does not list any cache
-   disks; Traffic Server is running in proxy-only mode. You must add
-   the disks you want to use for the cache to :file:`storage.config`.
-
-Traffic Server Alarm Messages
-=============================
-
-``[Rollback::Rollback] Config file is read-only: <filename>``
-   Go to the Traffic Server ``config`` directory and check the
-   indicated file permissions; change if necessary.
-
-``[Rollback::Rollback] Unable to read or write config file <filename>``
-   Go to the Traffic Server ``config`` directory and make sure the
-   indicated file exists. Check permissions and modify if necessary.
-
-``[Traffic Manager] Configuration File Update Failed: <error number>``
-   Go to the Traffic Server ``config`` directory and check the
-   indicated file permissions; change if necessary.
-
-``[Traffic Manager] Mgmt <==>Proxy conn. closed``
-   An informational message to inform you that the :program:`traffic_server`
-   process is down.
-
-``Access logging suspended - configured space allocation exhausted.``
-   The space allocated to the event log files is full; you must either
-   increase the space or delete some log files so that access logging
-   to continue. To prevent this error, consider rolling log files more
-   frequently and enabling the autodelete feature.
-
-``Access logging suspended - no more space on the logging partition.``
-   The entire partition containing the event logs is full; you must
-   delete or move some log files to enable access logging to continue.
-   To prevent this error, consider rolling log files more frequently
-   and enabling the autodelete feature.
-
-``Created zero length place holder for config file <filename>``
-   Go to the Traffic Server ``config`` directory and check the
-   indicated file. If it is indeed zero in length, then use a backup
-   copy of the configuration file.
-
-``Traffic Server could not open logfile <filename>``
-   Check permissions for the indicated file and the logging directory.
-
-``Traffic Server failed to parse line <line number> of the logging config file <filename>``
-   Check your custom log configuration file; there could be syntax
-   errors. Refer to :ref:`custom-logging-fields` for correct custom log format fields.
-
-``vip_config binary is not setuid root, manager will be unable to enable virtual ip addresses``
-   The :program:`traffic_manager` process is not able to set virtual IP
-   addresses. You must ``setuid root`` for the ``vip_config`` file in
-   the Traffic Server ``bin`` directory.
-
-.. _body-factory:
-
-HTML Messages Sent to Clients
-=============================
-
-Traffic Server returns detailed error messages to client browsers when there are
-problems with the HTTP transactions requested by the browser. These Traffic
-Server response messages correspond to standard HTTP response codes, but provide
-more information. A list of the more frequently encountered HTTP response codes
-is provided in :ref:`standard-http-response-messages`.
-
-The error messages can be customized. The actual response is generated from a template. These
-templates are stored in files which means the errors responses can be customized by modifying these
-files. The default directory for the template files is ``PREFIX/body_factory/default``
-but this can be changed by the configuration variable
-:ts:cv:`proxy.config.body_factory.template_sets_dir`. All files in this directory are added to a
-lookup table which is consulted when the error message is generated. The name used for lookup is by
-default that listed in the :ref:`following table <body-factory-error-table>`. It can be overridden by
-:ts:cv:`proxy.config.body_factory.template_base` which, if set, is a string that is prepended to the
-search name along with an underscore. For example, if the default lookup name is
-``cache#read_error`` then by default the response will be generated from the template in the file
-named ``cache#read_error``. If the template base name were set to "apache" then the lookup would
-look for a file named ``apache_cache#read_error`` in the template table. This can be used to switch
-out error message sets or, because this variable is overridable, to select an error message set
-based on data in the transaction.
-
-The text for an error message is processed as if it were a :ref:`custom logging format <custom-logging-fields>` which
-enables customization by values present in the transaction for which the error occurred.
-
-The following table lists the hard-coded Traffic Server HTTP messages,
-with corresponding HTTP response codes and customizable files.
-
-.. _body-factory-error-table:
-
-``Access Denied``
-   ``403``
-   You are not allowed to access the document at location ``URL``.
-   ``access#denied``
-
-``Cache Read Error``
-   ``500``
-   Error reading from cache; please retry request.
-   ``cache#read_error``
-
-``Connection Timed Out``
-   ``504``
-   Too much time has elapsed since the server has sent data.
-   ``timeout#inactivity``
-
-``Content Length Required``
-   ``400``
-   Could not process this request because ``Content-Length`` was not specified.
-   ``request#no_content_length``
-
-``Cycle Detected``
-   ``400``
-   Your request is prohibited because it would cause an HTTP proxy cycle.
-   ``request#cycle_detected``
-
-``Forbidden``
-    ``403``
-    ``<port number>`` is not an allowed port for SSL connections (you have made a request for a secure SSL connection to a forbidden port  number).
-    ``access#ssl_forbidden``
-
-``Host Header Required``
-   ``400``
-   An attempt was made to transparently proxy your request, but this
-   attempt failed because your browser did not send an HTTP ``Host``
-   header. Manually configure your browser to use
-   ``http://<proxy name>:<proxy port>`` as the HTTP
-   proxy. Alternatively, end users can upgrade to a browser that
-   supports the HTTP ``Host`` header field.
-   ``interception#no_host``
-
-``Host Header Required``
-   ``400``
-   Because your browser did not send a ``Host`` HTTP header field, the
-   virtual host being requested could not be determined. To access the
-   website correctly, you must upgrade to a browser that supports the
-   HTTP ``Host`` header field.
-   ``request#no_host``
-
-``HTTP Version Not Supported``
-   ``505``
-   The origin server ``<server name>`` is using an unsupported version
-   of the HTTP protocol.
-   ``response#bad_version``
-
-``Invalid Content Length``
-   ``400``
-   Could not process this request because the specified ``Content-Length``
-   was invalid (less than 0)..
-   ``request#invalid_content_length``
-
-``Invalid HTTP Request``
-   ``400``
-   Could not process this ``<client request>`` HTTP method request for ``URL``.
-   ``request#syntax_error``
-
-``Invalid HTTP Response``
-   ``502``
-   The host ``<server name>`` did not return the document ``URL`` correctly.
-   ``response#bad_response``
-
-``Malformed Server Response``
-   ``502``
-   The host ``<server name>`` did not return the document ``URL`` correctly.
-   ``response#bad_response``
-
-``Malformed Server Response Status``
-   ``502``
-   The host ``<server name>`` did not return the document ``URL`` correctly.
-   ``response#bad_response``
-
-``Maximum Transaction Time exceeded``
-   ``504``
-   Too much time has elapsed while transmitting document ``URL``.
-   ``timeout#activity``
-
-``No Response Header From Server``
-   ``502``
-   The host ``<server name>`` did not return the document ``URL`` correctly.
-   ``response#bad_response``
-
-``Not Cached``
-   ``504``
-   This document was not available in the cache, and you (the client)
-   only accept cached copies.
-   ``cache#not_in_cache``
-
-``Not Found on Accelerator``
-   ``404``
-   The request for ``URL`` on host ``<server name>`` was not found.
-   Check the location and try again.
-   ``urlrouting#no_mapping``
-
-``NULL``
-   ``502``
-   The host ``<hostname>`` did not return the document ``URL`` correctly.
-   ``response#bad_response``
-
-``Proxy Authentication Required``
-   ``407``
-   Please log in with username and password.
-   ``access#proxy_auth_required``
-
-``Server Hangup``
-   ``502``
-   The server ``<hostname>`` closed the connection before the transaction was completed.
-   ``connect#hangup``
-
-``Temporarily Moved``
-   ``302``
-   The document you requested, ``URL``, has moved to a new location. The new location is ``<new URL>``.
-   ``redirect#moved_temporarily``
-
-``Transcoding Not Available``
-   ``406``
-   Unable to provide the document ``URL`` in the format requested by your browser.
-   ``transcoding#unsupported``
-
-``Tunnel Connection Failed``
-   ``502``
-   Could not connect to the server ``<hostname>``.
-   ``connect#failed_connect``
-
-``Unknown Error``
-   ``502``
-   The host ``<hostname>`` did not return the document ``URL`` correctly.
-   ``response#bad_response``
-
-``Unknown Host``
-   ``500``
-   Unable to locate the server named ``<hostname>``; the server does
-   not have a DNS entry. Perhaps there is a misspelling in the server
-   name or the server no longer exists; double-check the name and try
-   again.
-   ``connect#dns_failed``
-
-``Unsupported URL Scheme``
-   ``400``
-   Cannot perform your request for the document ``URL`` because the
-   protocol scheme is unknown.
-   ``request#scheme_unsupported``
-
-
-.. _standard-http-response-messages:
-
-Standard HTTP Response Messages
--------------------------------
-
-The following standard HTTP response messages are provided for your
-information.
-
-======== ===================================
-Code     Description
-======== ===================================
-``200``  OK
-``202``  Accepted
-``204``  No Content
-``206``  Partial Content
-``300``  Multiple Choices
-``301``  Moved Permanently
-``302``  Found
-``303``  See Other
-``304``  Not Modified
-``400``  Bad Request
-``401``  Unauthorized; retry
-``403``  Forbidden
-``404``  Not Found
-``405``  Method Not Allowed
-``406``  Not Acceptable
-``408``  Request Timeout
-``500``  Internal Server Error
-``501``  Not Implemented
-``502``  Bad Gateway
-``504``  Gateway Timeout
-======== ===================================
-
-More detail can be found in `RFC2616 <http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html>`_
-which defines the full range of standardized HTTP/1.1 response codes.

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/ce162a6d/doc/admin/transparent-proxy.en.rst
----------------------------------------------------------------------
diff --git a/doc/admin/transparent-proxy.en.rst b/doc/admin/transparent-proxy.en.rst
deleted file mode 100644
index 7cb76f3..0000000
--- a/doc/admin/transparent-proxy.en.rst
+++ /dev/null
@@ -1,118 +0,0 @@
-.. _transparent-proxy:
-
-Transparent Proxying
-********************
-
-.. Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-   distributed with this work for additional information
-   regarding copyright ownership.  The ASF licenses this file
-   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
-   KIND, either express or implied.  See the License for the
-   specific language governing permissions and limitations
-   under the License.
-
-.. toctree::
-   :maxdepth: 2
-
-   transparent-proxy/build.en
-   transparent-proxy/bridge.en
-   transparent-proxy/router-inline.en
-   transparent-proxy/wccp-configuration.en
-   transparent-proxy/wccp-service-config.en
-
-Transparent Proxying is the ability of a proxy (such as ATS) to
-intercept connections between clients and servers without being visible.
-
-The general network structure that will be used in this documentation is
-shown in the following figure.
-
-.. figure:: ../static/images/admin/ats-basic-traffic.png
-   :align: center
-   :alt: ATS basic traffic flow of Transparent Proxy
-
-   ATS basic traffic flow of Transparent Proxy
-
-There must be a gateway device through which all network traffic passes
-from the client to the Internet (or external cloud). The gateway is
-responsible for effectively splicing ATS in to selected streams of that
-traffic. Each traffic stream is split in two, with ATS terminating
-both sides. That is, stream green-1, red-2, is split in to the green
-connection and the red connection. Note that ATS may or may not be on
-the gateway system, the redirected traffic can flow over other network
-infrastructure.
-
-Because ATS uses two connections, transparency can be set independently
-on the client and origin server (Internet / external cloud) side. We
-will define what is generally called "transparent proxy" as two aspects,
-*inbound transparency* and *outbound transparency*.
-
-Inbound transparency is a proxy that is transparent to connections that
-are inbound to the proxy, i.e. a connection initiated by a client which
-connects to the proxy (green-1). Similarly, outbound transparency is a
-proxy that is transparent to connections that are outbound from the
-proxy, i.e. a connection initiated by the proxy to an origin server
-(red-2).
-
-In most situations these two types of transparency are combined, but that is
-not required. Traffic Server supports transparency independently on the two
-sides. 
-
-.. important::
-
-    It is critical to note that any transparency requires specialized
-    routing and cannot be done solely by configuring ATS. ATS transparency
-    also requires support from the Linux kernel and therefore currently only
-    works on sufficiently recent Linux kernels that support the following
-    features:
-
-    -  TPROXY
-    -  POSIX capabilities
-
-    In addition the specialized routing will require using ``iptables`` and
-    in some cases ``ebtables``.
-
-Standard build procedures should work for transparency support but if
-not consult these :ref:`more detailed instructions <building-ats-for-transparency>`.
-
-Transparency is configured per server port, not globally. This is done
-via the configuration values :ts:cv:`proxy.config.http.server_ports`.
-In addition, :ts:cv:`proxy.config.reverse_proxy.enabled` must be enabled if the
-client side is transparent. That should be fixed in a future patch.
-
-.. XXX has that been fixed?
-
-.. XXX revisit section below
-
-In the first case use the attribute character (replacing the default
-'X')
-
-**Attribute** **Transparency Style** **Reverse Proxy**
-
-``=``
-    Full transparency: either
-
-``>``
-    Inbound (client) transparency: enabled
-
-``<``
-    Outbound (origin server) transparency: either
-
-In the outbound transparent case clients must connect directly to ATS
-either through an explicit proxy mechanism or by advertising the IP
-address of the ATS server via DNS as the origin server address.
-
-Some tested scenarios --
-
--  :doc:`transparent-proxy/bridge.en`
--  :doc:`transparent-proxy/router-inline.en`
--  :doc:`transparent-proxy/wccp-configuration.en`
-

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/ce162a6d/doc/admin/transparent-proxy/bridge.en.rst
----------------------------------------------------------------------
diff --git a/doc/admin/transparent-proxy/bridge.en.rst b/doc/admin/transparent-proxy/bridge.en.rst
deleted file mode 100644
index 8435ad9..0000000
--- a/doc/admin/transparent-proxy/bridge.en.rst
+++ /dev/null
@@ -1,177 +0,0 @@
-Inline on a Linux Bridge
-************************
-
-.. Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-   distributed with this work for additional information
-   regarding copyright ownership.  The ASF licenses this file
-   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
-   KIND, either express or implied.  See the License for the
-   specific language governing permissions and limitations
-   under the License.
-
-
-
-A Linux can be configured to operate in `bridge mode <http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge>`_.
-Two or more physical interfaces are assigned to the bridge. A single IP
-address is shared across the interfaces. By default any packet that
-arrives on one interface is immediately routed out another bridge
-interface.
-
-Linux packages required:
-
--  bridge-utils
--  ebtables
-
-In our example of setting up bridge mode we will use a local address of
-192.168.1.11/24 and interfaces ``eth0`` and ``eth1`` as the bridge
-interfaces (more detailed documentation is available
-`here <http://www.tldp.org/HOWTO/BRIDGE-STP-HOWTO/preparing-the-bridge.html>`_).
-You may omit the '#' character and everything after it. ::
-
-   brctl addbr br0 # create bridge device
-   brctl stp br0 off # Disable spanning tree protocol
-   brctl addif br0 eth0 # Add eth0 to bridge
-   brctl addif br0 eth1 # Add eth1 to bridge
-
-   ifconfig eth0 0 0.0.0.0 # Get rid of interface IP addresses
-   ifconfig eth1 0 0.0.0.0 # ditto # Set the bridge IP address and enable it
-   ifconfig br0 192.168.1.11 netmask 255.255.255.0 up
-
-If you have not already done so, remember to add a default route, such
-as this one for a gateway of 192.168.1.1. ::
-
-   ip route add default via 192.168.1.1
-
-At this point it is a good idea to test connectivity to verify the basic
-bridge is functional.
-
-Once the bridge is verified to work, this is the basic traffic pattern
-of interest.
-
-.. figure:: ../../static/images/admin/ats-traffic-bridge.png
-   :align: center
-   :alt: Picture of traffic flow through a bridge with ATS
-
-   Picture of traffic flow through a bridge with ATS
-
-The green arrows are packets originating from the client and the red
-arrows are packets originating from the origin server. All traffic not
-directed to the local address will pass through the bridge. We need to
-break into some of the traffic and subject it to routing so that it can
-be routed to ATS. This requires ``ebtables``. The flows we want to
-intercept are green 1 (from client to bridge) and red 1 (origin server
-to bridge).
-
-In this example we will intercept port 80 (HTTP) traffic. We will use
-the ``BROUTING`` chain because it is traversed only for packets that
-originated externally and arrived on a (forwarding enabled) interface.
-Although it looks like this will intercept all port 80 traffic it will
-only affect the two flows described above. ``-j redirect`` marks the
-packet as being diverted to the bridge and not forwarded, and the
-``DROP`` target puts the packets in the normal ``iptables`` routing so
-that we can use standard device tests on them [1]_. Although this
-example handles only port 80, other ports are the same except for the
-port value. Note also the port here is the port from the point of view
-of the clients and origin servers, not the Traffic Server server port. ::
-
-   ebtables -t broute -F # Flush the table
-   # inbound traffic
-   ebtables -t broute -A BROUTING -p IPv4 --ip-proto tcp --ip-dport 80 \
-     -j redirect --redirect-target DROP
-   # returning outbound traffic
-   ebtables -t broute -A BROUTING -p IPv4 --ip-proto tcp --ip-sport 80 \
-     -j redirect --redirect-target DROP
-
-Traffic Server operates at layer 3 so we need to use ``iptables`` to
-handle IP packets appropriately.::
-
-   iptables -t mangle -A PREROUTING -i eth1 -p tcp -m tcp --dport 80 \
-     -j TPROXY --on-ip 0.0.0.0 --on-port 8080 --tproxy-mark 1/1
-   iptables -t mangle -A PREROUTING -i eth0 -p tcp -m tcp --sport 80 \
-      -j MARK --set-mark 1/1
-
-At this point the directionality of the interfaces matters. For the
-example ``eth1`` is the inbound (client side) interface, while ``eth0``
-is the outbound (origin server side) interface. We mark both flows of
-packets so that we can use policy routing on them. For inbound packets
-we need to use ``TPROXY`` to force acceptance of packets to foreign IP
-addresses. For returning outbound packets there will be a socket open
-bound to the foreign address, we need only force it to be delivered
-locally. The value for ``--on-ip`` is 0 because the target port is
-listening and not bound to a specific address. The value for
-``--on-port`` must match the Traffic Server server port. Otherwise its
-value is arbitrary. ``--dport`` and ``--sport`` specify the port from
-the point of view of the clients and origin servers.
-
-Once the flows are marked we can force them to be delivered locally via
-the loopback interface via a policy routing table.::
-
-   ip rule add fwmark 1/1 table 1
-   ip route add local 0.0.0.0/0 dev lo table 1
-
-The marking used is arbitrary but it must be consistent between
-``iptables`` and the routing rule. The table number must be in the range
-1..253.
-
-To configure Traffic Server set the following values in
-:file:`records.config`
-
-- :ts:cv:`proxy.config.http.server_ports` *value from* ``--on-port`` (see below)
-
-- :ts:cv:`proxy.config.reverse_proxy.enabled` ``1``
-
-- :ts:cv:`proxy.config.url_remap.remap_required` ``0``
-
-You may also need to set :ts:cv:`proxy.config.cluster.ethernet_interface` to
-"br0" (the name of the bridge interface from the Bridge Commands).
-
-Additional troubleshooting
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-* Check to make sure that ``iptables`` is not filtering (blocking)
-  incoming HTTP connections.
-
-   It is frequently the case that the default tables prevent incoming HTTP. You can clear all filters with the
-   commands::
-
-      iptables -t filter --flush FORWARD
-      iptables -t filter --flush INPUT
-
-   That is a bit drastic and should only be used for testing / debugging. A
-   live system will likely need some filters in place but that is beyond
-   the scope of this document. If this fixes the problem, then your filter
-   set is too restrictive.
-
-   Note that this problem will prevent the basic bridge (without ATS) from
-   allowing HTTP traffic through.
-
-* Verify that IP packet forwarding is enabled.
-
-   You can check this with::
-
-      cat /proc/sys/net/ipv4/ip_forward
-
-   The output should be a non-zero value (usually '1'). If it is zero, you
-   can set it with::
-
-      echo '1' > /proc/sys/net/ipv4/ip_forward
-
-   This can setting can be persisted by putting it in ``/etc/sysctl.conf``: ::
-
-      net/ipv4/ip_forward=1
-
-.. rubric:: Footnotes
-
-.. [1]
-   The ``--redirect-target`` can be omitted, but then the ``iptables``
-   rules would need to use ``--physdev`` instead of just ``-i``. The
-   actual packet processing is identical.

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/ce162a6d/doc/admin/transparent-proxy/build.en.rst
----------------------------------------------------------------------
diff --git a/doc/admin/transparent-proxy/build.en.rst b/doc/admin/transparent-proxy/build.en.rst
deleted file mode 100644
index e547a06..0000000
--- a/doc/admin/transparent-proxy/build.en.rst
+++ /dev/null
@@ -1,60 +0,0 @@
-.. _building-ats-for-transparency:
-
-Building ATS for transparency
-*****************************
-
-.. Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-  distributed with this work for additional information
-  regarding copyright ownership.  The ASF licenses this file
-  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
-  KIND, either express or implied.  See the License for the
-  specific language governing permissions and limitations
-  under the License.
-
-
-In most cases, if your environment supports transparency then
-``configure`` will automatically enable it. For other environments you
-may need to twiddle the ``configure`` options.
-
-``--enable-posix-cap``
-    This enables POSIX capabilities, which are required for
-    transparency. These are compiled in by default. To check your
-    system, look for the header file ``sys/capability.h`` and the system
-    library ``libcap``. These are in the packages ``libcap`` and
-    ``libcap-devel`` or ``libcap-dev`` (depending on the Distribution)
-    contra-respectively.
-
-``--enable-tproxy[=value]``
-    Enable TPROXY support, which is the Linux kernel feature used for
-    transparency. This should be present in the base installation, there
-    is no package associated with it. \* ``auto`` Do automatic checks
-    for the the TPROXY header file (``linux/in.h``) and enable TPROXY
-    support if the ``IP_TRANSPARENT`` definition is present. This is the
-    default if this option is not specified or ``value`` is omitted. \*
-    ``no`` Do not check for TPROXY support, disable support for it. \*
-    ``force`` Do not check for TPROXY support, enable it using the $ats@
-    built in value for ``IP_TRANSPARENT``. This is useful for systems
-    that have it in the kernel for but some reason do not have the
-    appropriate system header file. \* *number* Do not check for TPROXY
-    support, use *number* as the ``IP_TRANSPARENT`` value. There are, at
-    present, no known standard distributions of Linux that support
-    TPROXY but use a value different from the built in ATS default.
-    However, a custom built kernel may do so and in that case the
-    specific value can be specified.
-
-In the default case, ATS configuration will automatically check for
-TPROXY support via the presence of the ``linux/in.h`` header file and
-compile in TPROXY support if it is available. If that fails, you may be
-able to recover by using one of the options above. Note that
-transparency may be built in by default but it is not active unless
-explicitly enabled in the ATS configuration files.
-

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/ce162a6d/doc/admin/transparent-proxy/router-inline.en.rst
----------------------------------------------------------------------
diff --git a/doc/admin/transparent-proxy/router-inline.en.rst b/doc/admin/transparent-proxy/router-inline.en.rst
deleted file mode 100644
index 0e9060a..0000000
--- a/doc/admin/transparent-proxy/router-inline.en.rst
+++ /dev/null
@@ -1,87 +0,0 @@
-Inline on a Linux router
-************************
-
-.. Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-  distributed with this work for additional information
-  regarding copyright ownership.  The ASF licenses this file
-  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
-  KIND, either express or implied.  See the License for the
-  specific language governing permissions and limitations
-  under the License.
-
-The routed set up presumes the set of clients are on distinct networks
-behind a single physical interface. For the purposes of this example
-will we presume
-
--  The clients are on network 172.28.56.0/24
--  The router connects the networks 172.28.56.0/24 and 192.168.1.0/24
--  Interface ``eth0`` is on the network 192.168.1.0/24
--  Interface ``eth1`` is on the network 172.28.56.0/24
--  The router is already configured to route traffic correctly for the
-   clients.
-
-In this example we will intercept port 80 (HTTP) traffic that traverses
-the router. The first step is to use ``iptables`` to handle IP packets
-appropriately.
-
-::
-
-    # reflow client web traffic to TPROXY
-    iptables -t mangle -A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j TPROXY \
-       --on-ip 0.0.0.0 --on-port 8080 --tproxy-mark 1/1
-    # Let locally directed traffic pass through.
-    iptables -t mangle -A PREROUTING -i eth0 --source 192.168.1.0/24 -j ACCEPT
-    iptables -t mangle -A PREROUTING -i eth0 --destination 192.168.1.0/24 -j ACCEPT
-    # Mark presumed return web traffic
-    iptables -t mangle -A PREROUTING -i eth0 -p tcp -m tcp --sport 80 -j MARK --set-mark 1/1
-
-We mark packets so that we can use policy routing on them. For inbound
-packets we use ``TPROXY`` to make it possible to accept packets sent to
-foreign IP addresses. For returning outbound packets there will be a
-socket open bound to the foreign address, we need only force it to be
-delivered locally. The value for ``--on-ip`` is 0 because the target
-port is listening and not bound to a specific address. The value for
-``--on-port`` must match the Traffic Server server port. Otherwise its
-value is arbitrary. ``--dport`` and ``--sport`` specify the port from
-the point of view of the clients and origin servers. The middle two
-lines exempt local web traffic from being marked for Traffic Server --
-these rules can be tightened or loosened as needed. They server by
-matching traffic and exiting the ``iptables`` processing via ``ACCEPT``
-before the last line is checked.
-
-Once the flows are marked we can force them to be delivered locally via
-the loopback interface via a policy routing table.
-
-::
-
-    ip rule add fwmark 1/1 table 1
-    ip route add local 0.0.0.0/0 dev lo table 1
-
-The marking used is arbitrary but it must be consistent between
-``iptables`` and the routing rule. The table number must be in the range
-1..253.
-
-To configure Traffic Server set the following values in
-:file:`records.config`
-
-``proxy.config.http.server_ports``
-    ``STRING``
-    Default: *value from* ``--on-port``
-
-``proxy.config.reverse_proxy.enabled``
-    ``INT``
-    Default: ``1``
-
-``proxy.config.url_remap.remap_required``
-    ``INT``
-    Default: ``0``
-

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/ce162a6d/doc/admin/transparent-proxy/wccp-configuration.en.rst
----------------------------------------------------------------------
diff --git a/doc/admin/transparent-proxy/wccp-configuration.en.rst b/doc/admin/transparent-proxy/wccp-configuration.en.rst
deleted file mode 100644
index a36401c..0000000
--- a/doc/admin/transparent-proxy/wccp-configuration.en.rst
+++ /dev/null
@@ -1,156 +0,0 @@
-WCCP Configuration
-******************
-
-.. Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-  distributed with this work for additional information
-  regarding copyright ownership.  The ASF licenses this file
-  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
-  KIND, either express or implied.  See the License for the
-  specific language governing permissions and limitations
-  under the License.
-
-.. _wccp-configuration:
-
-.. toctree::
-   :maxdepth: 2
-
-`WCCP <http://cio.cisco.com/en/US/docs/ios/12_0t/12_0t3/feature/guide/wccp.html>`_
-is de-facto semi-standard used by routers to redirect network traffic to
-caches. It is available on most Cisco™ routers although it does not
-appear to be officially supported by Cisco. The primary benefits of WCCP
-are
-
--  If already have a router that supports WCCP inline you do not
-   have to change your network topology.
--  WCCP fails open so that if the Traffic Server machine fails, it is
-   bypassed and users continue to have Internet access.
-
-Use of WCCP only makes sense for client side transparency [1]_
-because if the clients are explicitly proxied by Traffic Server there's
-no benefit to WCCP fail open, as the clients will continue to directly
-access the unresponsive Traffic Server host. It would be better to
-adjust the routing tables on the router for explicit proxying.
-
-Because the router serves as the inline network element, Traffic Server
-must run on a separate host. This host can be located anywhere as long
-as Traffic Server is either on the same network segment or a GRE tunnel
-can be maintained between the Traffic Server host and the router.
-
-|important| This document presumes that the router is already properly
-configured to handle traffic between the clients and the origin servers.
-If you are not certain, verify it before attempting to configure Traffic
-Server with WCCP. This is also a good state to which to revert should
-the configuration go badly.
-
-Configuration overview
-======================
-
-Setting WCCP is a three step process, first configuring the router, the
-Traffic Server host, and Traffic Server.
-
-|image1| The router will **not** respond to WCCP protocol packets unless
-explicitly configured to do so. Via WCCP, the router can be made to
-perform packet interception and redirection needed by Traffic Server
-transparency. The WCCP protocol in effect acts as means of controlling a
-rough form of policy routing with positive heartbeat cutoff.
-
-The Traffic Server host system must also be configured using
-``iptables`` to accept connections on foreign addresses. This is done
-roughly the same way as the standard transparency use.
-
-Finally Traffic Server itself must be configured for transparency and
-use of WCCP. The former is again very similar to the standard use, while
-WCCP configuration is specific to WCCP and uses a separate configuration
-file, referred to by the :file:`records.config` file.
-
-The primary concern for configuration in which of three basic topologies
-are to be used.
-
--  Dedicated -- Traffic Server traffic goes over an interface that is
-   not used for client nor origin server traffic.
--  Shared -- Traffic Server traffic shares an interface with client or
-   server traffic.
--  Inside Shared -- Traffic Server and client traffic share an
-   interface.
--  Outside Shared -- Traffic Server and
-   origin server traffic share an interface.
-
-In general the dedicated topology is preferred. However, if the router
-has only two interfaces one of the shared topologies will be
-required [2]_ Click the links above for more detailed configuration
-information on a specific topology.
-
-Shared interface issues
------------------------
-
-A shared interface topology has additional issues compared to a
-dedicated topology that must be handled. Such a topology is required if
-the router has only two interfaces, and because of these additional
-issues it is normally only used in such cases, although nothing prevents
-it use even if the router has three or more interfaces.
-
-The basic concept for a shared interface is to use a tunnel to simulate
-the dedicated interface case. This enables the packets to be
-distinguished at layer 3. For this reason, layer 2 redirection cannot be
-used because the WCCP configuration cannot distinguish between packets
-returning from the origin server and packets returning from Traffic
-Server as they are distinguished only by layer 2 addressing [3]_.
-Fortunately the GRE tunnel used for packet forwarding and return can be
-used as the simulated interface for Traffic Server.
-
-Frequently encountered problems
--------------------------------
-
-MTU and fragmentation
-~~~~~~~~~~~~~~~~~~~~~
-
-In most cases the basic configuration using a tunnel in any topology can
-fail due to issues with fragmentation. The socket logic is unable to
-know that its packets will eventually be put in to a tunnel which will
-by its nature have a smaller
-`MTU <http://en.wikipedia.org/wiki/Maximum_transmission_unit>`_ than the
-physical interface which it uses. This can lead to pathological behavior
-or outright failure as the packets sent are just a little too big. It is
-not possible to solve easily by changing the MTU on the physical
-interface because the tunnel interface uses that to compute its own MTU.
-
-References
-==========
-
--  `WCCP Router Configuration Commands - IOS
-   12.2 <http://www.cisco.com/en/US/docs/ios/12_2/configfun/command/reference/frf018.html>`_
-
-
-
-
-
-
-
-
-.. [1]
-   Server side transparency should also be used, but it is not as
-   significant. In its absence, however, origin servers may see the
-   source address of connections suddenly change from the Traffic Server
-   address to client addresses, which could cause problems. Further, the
-   primary reason for not having server side transparency is to hide
-   client addresses which is defeated if the Traffic Server host fails.
-
-.. [2]
-   If your router has only one interface, it's hardly a *router*.
-
-.. [3]
-   This is not fundamentally impossible, as the packets are distinct in
-   layer
-
-.. |important| image:: ../../static/images/docbook/important.png
-.. |image1| image:: ../../static/images/docbook/important.png
-

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/ce162a6d/doc/admin/transparent-proxy/wccp-service-config.en.rst
----------------------------------------------------------------------
diff --git a/doc/admin/transparent-proxy/wccp-service-config.en.rst b/doc/admin/transparent-proxy/wccp-service-config.en.rst
deleted file mode 100644
index 7726ebe..0000000
--- a/doc/admin/transparent-proxy/wccp-service-config.en.rst
+++ /dev/null
@@ -1,75 +0,0 @@
-WCCP Service Configuration
-**************************
-
-.. Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-  distributed with this work for additional information
-  regarding copyright ownership.  The ASF licenses this file
-  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
-  KIND, either express or implied.  See the License for the
-  specific language governing permissions and limitations
-  under the License.
-
-.. _wccp-service-configuration:
-
-The service definition file is used by
-:ref:`traffic_wccp` and :ref:`traffic-server` directly.
-The elements in the security definition file are inspired by the `WCCP RFC (8/2012) <http://tools.ietf.org/html/draft-mclaggan-wccp-v2rev1-00>`_.  There is also an older version of the RFC that shows up commonly in search results, `WCCP (4/2001) <https://tools.ietf.org/id/draft-wilson-wrec-wccp-v2-01.txt>`_, and was the RFC reference used in the original WCCP support for Traffic Server several years ago.
-
-A sample service group file is included in the source tree under cmd/traffic_wccp.
-
-Security Section
-================
-
-In the security section, you can define a password shared between the WCCP Client and the WCCP router.  This password is used to encrypt the WCCP traffic.  It is optional, but highly recommended.
-
-Attributes in this section
-
-*  option  - Must be set to MD5 if you want to encrypt your WCCP traffic
-
-*  key – The same password that you set with the associated WCCP router.
-
-Services Section
-================
-
-In the services section you can define a list of service groups.  Each top level entry is a separate service group.  
-
-Service group attributes include
-
-*  name – A name for the service.  Not used in the rest of the WCCP processing.
-
-*  description – A description of the service.  Again, not used in the rest of the WCCP processing.
-
-*  id - The security group ID.  It must match the service group ID that has been defined on the associated WCCP router.  This is the true service group identifier from the WCCP perspective.  
-
-* type – This defines the type of service group either “STANDARD” or “DYNAMIC”.  There is one standard defined service group, HTTP with the id of 0.  The 4/2001 RFC indicates that id’s 0-50 are reserved for well known service groups.  But more recent 8/2012 RFC indicates that values 0 through 254 are valid service id’s for dynamic services.  To avoid differences with older WCCP routers, you probably want to  avoid dynamic service ID’s 0 through 50.  
-
-* priority – This is a value from 0 to 255.  The higher number is a higher priority.  Well known (STANDARD) services are set to a value of 240.  If there are multiple service groups that could match a given packet, the higher priority service group is applied. RFC  For example, you have service group 100 defined for packets with destination port 80, and service group 101 defined for packets with source port 1024.  For a packet with destination port set to 80 and source port set to 1024, the priorities of the service groups would need to be compared to determine which service group applies.
-
-* protocol – This is IP protocol number that should match.  Generally this is set to 6 (TCP) or 17 (UDP).
-
-* assignment – WCCP supports multiple WCCP clients supporting a single service group.  However, the current WCCP client implementation in Traffic Server assumes there is only a single WCCP client, and so creates assignment tables that will direct all traffic to that WCCP client.  The assignment type is either hash or mask, and if it is not set, it defaults to hash.  If Traffic Server ever supports more than one cache, it will likely only support a balanced hash assignment.  The mask/value assignment seems to be better suited to situations where the traffic needs to be more strongly controlled.
-
-* primary-hash – This is the element of the packet that is used to compute the primary key.  The value options are src_ip, dst_ip, src_port, or  dst_port. This entry is a list, so multiple values can be specified.  In that case, all the specified packet attributes will be used to compute the hash bucket.  In the current implementation, the primary hash value does not matter, since the client always generates a hash table that directs all matching traffic to it.  But if multiple clients are ever supported, knowledge of the local traffic distribution could be used to pick a packet attribute that will better spread traffic over the WCCP clients.
-*  alt-hash – The protocol supports a two level hash.  This attribute is a list with the same value options as for primary-hash.  Again, since the current Traffic Server implementation only creates assignment tables to a single client, specifying the alt-hash values does nothing.  
-
-* ports – This is a list of port values.  Up to 8 port values may be included in a service group definition.  
-
-* port-type – This attribute can have the value of src or dst.  If not specified, it defaults to dst.  It indicates whether the port values should be interpreted as source ports or destination ports.
-
-* forward – This is a list.  The list of the values can be GRE or L2.  This advertises how the client wants to process WCCP packets.  GRE means that the packets will be delivered in a GRE tunnel.  This is the default.  L2 means that the client is on the same network and can get traffic delivered to it from the router by L2 routing (MAC addresses).
-
-* return – The WCCP protocol allows a WCCP client to decline a packet and return it back to the router.  The current WCCP client implementation never does this.  The value options are the same as for the forward attribute.
-
-* routers – This is the list of router addresses the WCCP client communicates with.  The WCCP protocols allows for multiple WCCP routers to be involved in a service group.  The multiple router scenario has at most been lightly tested in the Traffic Server implementation.
-
-* proc-name – This attribute is only used by traffic_wccp.  It is not used in the traffic_server WCCP support.  This is the path to a process’ PID file.  The service group is advertised to the WCCP router if the process identified in the PID file is currently operational.
-


Mime
View raw message