HAT automatically manipulates all the headers in all requests and responses. The manipulation of the body of the transaction, however, depends on its content, as follows:

• In requests, body data is manipulated in the following content types:
  
  
  • XML: text/xml
    
    
  • POST requests containing forms of the following type:
    
    application/x-www-form-urlencoded
    
    
• In responses, body data is manipulated in the following content types:
  
  
  • text/<suffix>, where <suffix> can be any type of text, for example: text/html, text/css, text/plain
    
    
  • application/x-javascript (to a limited extent)
    
    

Note:
If your applications require the manipulation of other types of content, you can configure additional content types.

In order to streamline the manipulation of body content to conform to your applications, you can configure the types of tags each parser manipulates, or you can add token-to-token replacement, search and replace, and signature-injection mechanisms for content that cannot be handled by the parser. You can also exclude parsing in irrelevant data, for performance tuning.

Tip:
Because requests are always manipulated after they pass the filter’s content inspection, the inspection rules you configure for the trunk are not affected by the manipulation described here.

The filter modifies the following types of URLs in body data:

• Absolute URL: includes the scheme, the server name, and the full path to the page.
  
  For example:
  
  http://www.contoso .com/resources/system/egap.htm
  
  
• Absolute path: representation of the location of the page, relative to the server on which it resides.
  
  For example:
  
  /resources/system/egap.htm
  
  
• Net path: the browser adds the path to the scheme used in the current URL.
  
  For example:
  
  //www.contoso.com/resources/system/egap.htm
  
  

The filter manipulates URLs of the types described above on their way out of the organization, by adding a unique signature. When an HTML file is received from an application server, the filter signs all the relevant links in the file.

The signature is composed of the following:

• Unique Identifier.Forefront UAG automatically assigns an identifier to the site the first time you configure a trunk.
  
  
• Encrypted Data, as determined by the filter.
  
  
• Unique Identifier with an additional suffix, which indicates whether Forefront UAG uses Secure Sockets Layer (SSL) to communicate with the application server or not, in the following format:
  
  
  • <Unique Identifier>0
    
    Forefront UAG does not use SSL to communicate with the application server
    
    
  • <Unique Identifier>1
    
    Forefront UAG uses SSL to communicate with the application server
    
    

For example:

If the organization’s unique identifier is OurID, the encrypted data created by the Forefront UAG filter is xyz, and Forefront UAG communicated with the application server using SSL, the signature is: OurIDxyz/OurID1

In this example, if the filter receives a file from the server www.contoso.com, using SSL, and the file contains two links that require manipulation, it signs the links as follows:

In this example, if the user requests the second link, the browser sends a request for the following URL:

/OurIDxyz/OurID1/a.html

The filter receives the request and translates the URL to the following:

/a.html

The filter then sends the translated request to the following server:

www.contoso.com

The filter processes incoming requests in the following order:

1. Determines whether the requested URL is recognized. A recognized URL is either the portal homepage or a URL that was processed by the filter when the link was sent to the client.
   
   
   • If the URL is recognized, the filter goes on to determine whether the application which it resolved in the URL is configured for access via the portal, in the Applications list of the Forefront UAG Management console.
     
     
   • If the application is in the Applications list, the filter manipulates the request header, as described later on in this flow.
     
     
   • If the application is not in the Applications list, the filter returns a “Server Error” message to the client.
     
     
   • If the URL is unrecognized, the filter checks whether it appears in the URL Replacement list.
     
     
   • If the URL appears in the URL Replacement list, the filter replaces the URL and then goes on to manipulate the request header, as described later on in this flow.
     
     
   • If the unrecognized URL is not on the URL Replacement list, the filter checks whether the HTTP request contains a HATServerCookie header. This cookie contains the server from which the last response was sent. If the HATServerCookie is found, the request is attributed to the server found in the cookie. The filter then goes on to manipulate the request header, as described in the next step.
     
     
   • If the HTTP request does not contain a HATServerCookie, the filter returns a “Request Error” message to the client.
     
     
2. The filter manipulates the request header.
   
   
3. The filter determines whether data manipulation is required in the body of the request, according to the content type.
   
   
   • If the request contains data that needs to be manipulated, the filter goes on to the next step.
     
     
   • If the request does not contain data that needs to be manipulated, the filter sends the request to the application.
     
     
4. If the request contains data types that require manipulation, the filter checks whether the requested URL is configured so that body parsing is skipped.
   
   
   • If body parsing is required, the filter goes on to the next step.
     
     
   • If body parsing is skipped, the filter sends the request to the application.
     
     
5. The filter runs the applicable parser on the data.
   
   
6. The filter sends the request to the application.
   
   

The filter processes responses in the following order:

1. Manipulates the response header.
   
   
2. Determines whether data manipulation in the body of the response is required, according to the content type. (Content that never contains links, such as graphic files, is not manipulated, and the filter sends the response to the client.
   
   

Note:
Data that is received from the application server in chunk mode is transformed to content-length.

1. Once the filter establishes that the response requires manipulation, it checks whether the response is configured so that body parsing is skipped.
   
   
   • If body parsing is required, the filter goes on to the next step.
     
     
   • If body parsing is skipped, the filter sends the response to the client.
     
     
2. The filter checks whether data change is configured, and if it is, performs the necessary changes. Data change is used for token replacement and for signature injection.
   
   
3. The filter runs the applicable parser on the data, depending on the content type. The parsers manipulate the data so that, to the user, all links to the applications that are enabled via the AAP point to one site—the public host, that is, the external Web site. By default, all tags that can contain links are parsed. You can configure additional types of tags to parse.
   
   
4. If “Search and Replace Response Content” is enabled, the filter runs a search and replace parser on the entire content of the response, including tags that do not normally contain links.
   
   
5. The filter sends the response to the client.