|
Persistent Connection Timeout
|
The
maximum time in seconds the web proxy keeps open a connection to a client or
server after a transaction has been completed and no further activity is
detected.
If
you increase these values connections will remain open longer and reduce the
overhead used to open and close connections repeatedly. However, you also
reduce the ability of the Web Proxy to open new connections if the maximum
number of simultaneous persistent connections has been reached.
After establishing a connection and performing an SSL handshake, if client requests are not sent to the proxy, the proxy
waits for the persistent connection timeout, and then ceases its connection with the client.
Cisco
recommends keeping the default values.
|
|
In-Use Connection Timeout
|
The
maximum time in seconds that the web proxy waits for more data from an idle
client or server when the current transaction has not yet been completed.
|
|
Simultaneous Persistent Connections (Server Maximum Number)
|
The
maximum number of connections (sockets) the Web Proxy keeps open with servers.
|
|
Maximum Connections Per Client
|
Restricts the number of concurrent connections initiated by the client to a configured value. When the number of connections
exceed the configured limit, the connections are dropped, and an alert is sent to the administrator.
|
Note
|
By default, Maximum Connections Per Client is disabled.
|
To configure the limit, check the Maximum Connections Per Client check box, and do the following:
-
Connections—Enter the number of permissible concurrent connections.
-
Exempted Downstream Proxy or Load Balancer—Enter the IP address of the downstream proxy, load balancer, or any other client IP address (you cannot configure the subnets
or host names). The web proxy does not apply the restrictions of the concurrent connections on the IP addresses that are included
in this exempted list.
|
|
Generate Headers
|
Generate and add headers that encode information about the request.
-
X-Forwarded-For headers encode the IP address of the client from which an HTTP request originated.
|
Note
|
-
To turn header forwarding on or off, use the CLI advancedproxyconfig command, Miscellaneous option, “Do you want to pass HTTP X-Forwarded-For headers?”
-
Using an explicit forward upstream proxy to manage user authentication or access control with proxy authentication requires
forwarding of these headers.
-
For transparent HTTPS requests, the appliance does not decrypt the XFF header. For explicit requests, the appliance uses the
XFF header received in the CONNECT request, and does not decrypt the XFF inside the SSL tunnel, so identification of client
IP Addresses using X-Forwarded-For is not applicable for HTTPS transparent requests.
|
-
Request Side VIA headers encode the proxies through which the request passed on its way from the client to the server.
-
Response Side VIA headers encode the proxies through which the request passed on its way from the server to the client.
|
|
Use
Received Headers
|
Allows a Web proxy deployed as an upstream proxy to identify clients using
X-Forwarded-For headers send by downstream proxies. The Web Proxy will not
accept the IP address in a X-Forwarded-For header from a source that is not
included in this list.
If
enabled, requires the IP address of a downstream proxy or load balancer (you
cannot enter subnets or host names).
|
|
Range Request Forwarding
|
Use the Enable Range Request Forwarding check box to enable or disable forwarding of range requests. Refer to Web アプリケーションへのアクセスの管理 for more information.
|
フィードバック