Set up services for an application

These configurations of services for your application are optional and include:

Data compression services. By default Enterprise Application Access compresses all traffic. To disable compression, deselect the box.
URL rewrite services. Improve site delivery and optimize the content from your applications.
Internet Content Adaptation Protocol (ICAP) services. Service Chaining with Internet Content Adaptation Protocol (ICAP).
URL path-based services. When applications have specific URL paths that must be treated differently from URL paths to the main application, use URL path-based rules to enable or disable authentication or redirect to a different group of servers.

Data compression services

Disable default traffic compression.

Log in to Enterprise Center.
In the Enterprise Center navigation menu, select Application Access > Applications > Applications.
Select your application to open it.
In Services deselect Compression.
Click Save and Deploy, to save and deploy the changes.

URL rewrite services

In Enterprise Application Access you can configure URL rewrite rules globally, or by type.

Global rewrite rules may apply to all content types and make a general correction to the URL strings. If you use an Akamai domain as the external hostname for an application with absolute URLs, a global rule to rewrite the internal application name to the external application name delivers ease of use content rewriting.

URL rewriting improves site delivery by optimizing the content from your applications. In Enterprise Application Access URL rewrite rules are often necessary when internal and external hostnames for an application differ. For example, some links may try to serve content from the intranet to external users. In this case, the link fails and the application does not serve content. Once the URL path is rewritten, the link goes to the external site and is able to serve the content.

The below table describes five rewrite type options available that apply to either the response or the request to help fix broken links.

Content type	Description
Content rewrite	The internal path is in the original string and the external path is in the replacement string. Here Enterprise Application Access looks at the `response` packet to rewrite.
Post body rewrite	There is a body to content that is uploaded and posted in formats such as JSON, XML, or others. For post body rewrite, content is rewritten on its way back to the user from the server. The original string contains the external path and the replacement string contains the internal path. Here Enterprise Application Access looks at the `request` packet to rewrite.
Query body rewrite	A user may use the external path to write content. Here Enterprise Application Access looks at the `request` packet to rewrite.
Location rewrite	Here EAA Client looks at the `response` packet to rewrite.
Cookie rewrite	This is an uncommon case. Cookies are usually used to maintain the state of the application. If user is unexpectedly logged out of a session, a cookie rewrite rule may help. In this case, the original string carries the internal path and the replacement string carries the external path.

Rewrite groups allow you to apply rewrite rules across distinct applications that are related to one another.

Log in to Enterprise Center.
In the Enterprise Center navigation menu, select Application Access > Applications > Applications.
Select your application to open it.
Enable Services > Rewrite.
Click Add Rule (+).
Enter a name for the rule and click Add.
Click Edit Rule for the new rule you added. Complete the rewrite attribute fields.
Click Save Rule (✓).
To delete the rule, you can click the Delete rule to remove it.
Click Save and Deploy, to save and deploy the changes.

For groups see Create application groups for rewrite rules.

Internet Content Adaptation Protocol (ICAP) services

The Internet Content Adaptation Protocol (ICAP) is designed to offload the processing of Internet-based content to dedicated servers. ICAP helps free up resources and standardize how features are implemented. ICAP is a lightweight protocol for executing a remote procedure call on HTTP messages. It allows ICAP clients to pass HTTP messages to ICAP servers. Enterprise Application Access (EAA) allows administrators to do service chaining with existing, co-located security appliances that support ICAP protocol for further processing of files being sent to and from users. Examples of ICAP servers includes enterprise antivirus appliance, IPS/IDS service, and others.

EAA connectors are integrated with the ICAP servers, which allows them to scan the HTTP requests for malware and other threats. EAA supports scanning of GET, POST, and PUT HTTP methods, and additional techniques. When the user sends a supported request, the connector forwards it to the ICAP server. The ICAP server scans the content, like uploaded files, to find any malware. Based on the ICAP response, the EAA connector decides whether to block the response or forward the original request to the origin.

ICAP configuration options

The ICAP configuration fields are:

Service Name. Provide the name of the service that you wish to use from the ICAP server for scanning requests.
Host. Enter the host or IP address of the ICAP server where it is running.
Port. Enter the port number used by the ICAP server. The default entry is 1344.
Health Check. Connectivity between the connector and the ICAP server is checked every 30 seconds when enabled. To turn health checks on the ICAP server off, select OFF. To turn health checks for the ICAP server on, select either the ICAP or TCP. If you select TCP, health checks run using a TCP-only protocol.
HTTP methods. Select the HTTP methods that need to be sent to the ICAP server for scanning. Only these methods will be forwarded to the origin after scanning, otherwise they will be sent directly to the origin. Depending on the application the HTTP method may determine the directionality of the file transfer. For example, a POST may correspond to a file upload and a GET may correspond to the file download. Select the methods to specify the direction for file transfers to forward to the ICAP server for further processing. By default POST is selected.
Secure ICAP. Select this option to use a secure tunnel between the ICAP server and EAA connector. This is optional.
Max File Size. Enter the maximum file size, in megabytes, that should be sent to the ICAP server for scanning. By default, this is set to 500 MB.
Exceeds Max File Size. If the file exceeds the maximum file size, select one of these options:
- Deny (Default) This option rejects the file transfer to the user and is not sent for scanning.
- Ignore This option forwards the file transfer request to the application server without any scanning.
Block File Transfer. Enable this option, if you want to block transferring files to ICAP server using different blocking methods. Select one of the Blocking methods described below:
- HTTP status code. Block transferring of file to the ICAP server if it returns these specific HTTP status codes. Provide the codes as a comma separated list. For example, if you entered a 403 status code, when a post request is sent to the ICAP server, and malware is detected, the ICAP server responds with a 403 status code in message, the request is blocked immediately.
- HTTP response header. Block transferring of file to the ICAP server if the Response Header contains:
  - Header name. Provide the specific header name.
  - Header name and Header value Provide the specific header name and the header values.
    Note: Specifying only the Header value without a Header name is not allowed.
- DLP message (keyword match in HTTP body) Block transferring the file to the ICAP server if these keywords are in the HTTP response body. Provide the keywords as a comma separated list.
ICAP Failure behavior. Describe what type of behavior you want when the ICAP server is down temporarily.
- Fail close (Block traffic) Block traffic to ICAP server when it is down. The application will not be accessible by the user.
- Fail open (Allow traffic) Allow traffic to ICAP server when it is down. The application will be accessible by the user.

Configure Internet Content Adaptation Protocol (ICAP) for an application.

Log in to Enterprise Center.
In the Enterprise Center navigation menu, select Application Access > Applications > Applications.
Select your application to open it.
Enable Services > ICAP.
Click Add Rule (+).
Complete the ICAP configuration fields as necessary. Refer to the ICAP configuration options.
Click Save and Deploy, to save and deploy the changes.

URL path-based services

Applications may have one or more origin servers from which they serve content. These servers can be configured to handle a URL path and allow customers to specify a set of servers for each URL path. When applications have specific URL paths that must be treated differently from URL paths to the main application, use URL path-based rules to enable or disable authentication or redirect to a different group of servers. For example, if your application has a special content page located at http://myapp.com/content that is served from a different server than what the main application is served from, and requires no authentication, you can disable authentication to this URL path and redirect to a separate server group for just the /content URL path.

📘
Note
You cannot use wildcards in the URL path for path-based services.

In Enterprise Application Access URL path-based policies are an advanced configuration setting. Your rule can specify a load balancing group, configure server load balancing, and health check configuration attributes. Configuring URL paths in Enterprise Application Access helps to meet the configuration requirements of the applications themselves. If you do not define URL path-based rules, Enterprise Application Access default is to the main server set given in the application configuration.

Log in to Enterprise Center.
In the Enterprise Center navigation menu, select Application Access > Applications > Applications.
Select your application to open it.
Enable Services > URL path-based policies.
Click Add Rule (+).
Enter a name for the rule and a URL path.
Click Save Rule (✓).
Enter the IP address of the server to redirect traffic to.
Hover over the lens icon on the left of the rule. Make sure the health check configuration information is correct.
Click the Edit Rule and complete the server load balancing, health check configuration information.
Click Save and Deploy, to save and deploy the changes.