diff --git a/doc/admin-guide/configuration/transparent-proxy.en.rst b/doc/admin-guide/configuration/transparent-proxy.en.rst index 31ce623d7e6..9f1cfc27af4 100644 --- a/doc/admin-guide/configuration/transparent-proxy.en.rst +++ b/doc/admin-guide/configuration/transparent-proxy.en.rst @@ -1,3 +1,22 @@ +.. 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. + +.. include:: ../../common.defs + .. _transparent-proxy: Transparent Proxying @@ -84,32 +103,16 @@ Standard build procedures should work for transparency support but if not consult these :ref:`more detailed instructions `. 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 +via the configuration values :ts:cv:`proxy.config.http.server_ports`, specifically tr-in, tr-full, and tr-out. 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. +The :ts:cv:`proxy.config.http.use_client_target_addr` should also be reviewed when setting up an outbound +transparent scenario. If |TS| has the same DNS as the client, options 1 and 2 can be used. Otherwise, +option 2 must be used. + Some tested scenarios -- - :doc:`transparent-proxy/bridge.en` diff --git a/doc/admin-guide/files/records.config.en.rst b/doc/admin-guide/files/records.config.en.rst index a56fdf81d5b..29cc8c457d2 100644 --- a/doc/admin-guide/files/records.config.en.rst +++ b/doc/admin-guide/files/records.config.en.rst @@ -1121,10 +1121,10 @@ mptcp in the set of addresses found by the proxy, the request continues to the client specified address, but the result is not cached. ``2`` Enables the feature with no address verification. No DNS processing is - performed. The result is cached (if allowed otherwise). This option is - vulnerable to cache poisoning if an incorrect ``Host`` header is - specified, so this option should be used with extreme caution. See - bug TS-2954 for details. + performed. The result is cached (if allowed otherwise). + This option is vulnerable to cache poisoning if an incorrect ``Host`` header is + specified, so this option should be used with extreme caution if HTTP caching is + enabled. See bug TS-2954 for details. ===== ====================================================================== If all of these conditions are met, then the origin server IP address is