NetIQ Documentation: Novell Access Manager 3.1 SP5 Access Gateway Guide

7.5 Rewriter Issues

7.5.1 Discovering the Issue

To isolate a rewriter issue:

Go to the Web server, access the page that is causing the rewriter problem, use the View Source option of the browser, then copy the source to a text file.
Access the page from Access Manager, view the source, and copy it to a text file.
Use a diff tool to compare the differences between the two files.

This should help you identify the URLs that need to be rewritten but aren’t being rewritten.

7.5.2 Rewriting Fails on a Page with Numerous HREFs

Although the rewriting failure occurs when downloading large amounts of data from a protected Web server, it is not the size or the timeout of the page that is the issue. It is the number of links to be rewritten. The Access Gateway has a data size limit for the number of references that the rewriter can rewrite on a page.

The solution is to reduce the number of HREFs on the page that need to be rewritten. If the problem is occurring because the rewriter is rewriting HTTP to HTTPS, you can solve this problem by disabling multi-homing for the Web server and by rewriting the Web page to use relative links. This reduces the number of links that need to be rewritten.

7.5.3 Links Are Broken Because the Rewriter Sends the Request to the Wrong Proxy Service

When links on the Web server are rewritten to the wrong proxy service, the reverse proxy and Web servers might have the following configuration:

The initial request from the browser is to a path-based multi-homing proxy service.
The reverse proxy is configured to service one or more path-based proxy services.
The path-based proxy services are configured to Forward Received Host Name and to Remove Path on Fill.
The Web servers protected by these path-based proxy services have links to each other.

With this configuration, the rewriter cannot determine whether the link is to the current proxy service, one of the other path-based proxy services, or the parent proxy service. With the path removed, all the path-based proxy services have the same name. For example if one proxy service has the published name of mycompany.provo.novell.com/sales and a second path-based proxy service has a name of mycompany.provo.novell.com/app, the names are the same as the parent proxy service when the path is removed. The HTTP header does not help, because the proxy services are forwarding the same host name: mycompany.provo.novell.com.

There are a number of ways to solve this problem. One of the easiest ways is to set up DNS names for the Web servers, then configure the proxy services so that the Host Header option is set to Web Server Host Name and the DNS name of the Web server is specified in the Web Server Host Name field. This places the DNS name of the Web Server name in the HTTP Host header, allowing the rewriter to distinguish it from the other Web servers protected by the reverse proxy.

7.5.4 Reading Configuration Files

If the rewriter is successful in reading the configuration files, and you have enabled the log level to LOG_INFO, the following message is displayed in the /var/log/ics_dyn.log file:

Reading Config File

Aug 16 04:16:51 proxy140 LINUX_AG:REWRITER:0:Configuration information read successfully

For more information on configuring log levels, see Configuring Log Levels.

If the rewriter fails to read the configuration files, the following message is displayed:

Aug 16 04:16:51 proxy140 LINUX_AG:REWRITER:0:Reading configuration failed for ssTypeName=www.mynovell.com

If this happens, re-create the corresponding proxy service and restart the Access Gateway service.

7.5.5 Rewriter Does Not Rewrite Content in Files with a Non-Default Extension

The html, htm, shtml, jhtml, asp, jsp, js, php, and css content-type extensions are rewritten by default. If the Web server sends data with file extensions that do not match with any of the default rewriter profiles, the rewriter does not rewrite the content.

To work around this problem, do the following:

In the Administration Console, click Devices > Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > HTML Rewriting.
Do one of the following:
- If the Web server sends a different content type for a non-default file extension, then configure the new content type in the Content-Type Header.
- If the Web Server does not send any content type for a non-default extension, then configure extension/<file_extension> as the Content-Type Header. For example, if the data sent is http://www.myproxy.com/test.mytxt, then you must configure the Content-Type Header as extension/mytxt.

7.5.6 An Additional DNS Name without a Scheme Is Not Rewritten

The rewriter rewrites URLs based on the port configured for Connect Port, when a domain name without scheme is added to the additional URL list. For example, if the connect port is configured as 80, the rewriter rewrites only HTTP URLs and not HTTPS URLs.

To work around this problem,

In the Administration Console, click Devices > Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > HTML Rewriting.
Add the additional DNS name with the scheme in the Additional DNS Names List in the following format:

scheme://DNS_name

For example:
```
https://example.com
```

7.5.7 Rewriting a URL

Set the log level to LOG_DEBUG to view rewriter log messages in the /var/log/ics_dyn.log file. (See Configuring Log Levels.)

For example, if the rewriter successfully rewrites the URL, the following messages are displayed:

Aug 16 04:16:51 proxy140 LINUX_AG:REWRITER:0:URL:'http://www.mynovell.com:9090/common/inc/nav/main.js' Content type match, Will Rewrite
Aug 16 04:16:51 proxy140 LINUX_AG:REWRITER:0:URL:'http://www.mynovell.com:9090/common/inc/nav/main.js' Unknown Content-Type - automatic match - Will Rewrite
Aug 16 04:16:51 proxy140 LINUX_AG:REWRITER:0::'http://www.mynovell.com:9090/common/inc/nav/main.js' NULL Content-Type - automatic match - Will Rewrite
Aug 16 04:16:51 proxy140 LINUX_AG:REWRITER:0:In RewriterOption::shouldRewriteUrl, returning TRUE.
Aug 16 04:16:51 proxy140 LINUX_AG:REWRITER:0:URL:'http://www.mynovell.com:9090/common/inc/nav/main.js' Unknown extension - automatic match - Will Rewrite
Aug 16 04:16:51 proxy140 LINUX_AG:REWRITER:0:URL:'http://www.mynovell.com:9090/common/inc/nav/main.js' NULL extension - automatic match - Will Rewrite
Aug 16 04:16:51 proxy140 LINUX_AG:REWRITER:0:URL:'http://www.mynovell.com:9090/common/inc/nav/main.js' Extension type match - Will Rewrite

If the conditions for rewriting a URL fail, the following messages are displayed:

Aug 16 04:16:51 proxy140 LINUX_AG:REWRITER:0:URL:'http://www.mynovell.com:9090/favicon.ico' - Did not match INCLUDE list, Content-Type and Extension type
Aug 16 04:16:51 proxy140 LINUX_AG:REWRITER:0:In RewriterOption::shouldRewriteUrl, returning FALSE.

Check the rewriter configuration. Ensure that your content type, extension type, and include URL list are valid.

7.5.8 The Access Gateway Rewrites a Host Header with a Port Number

In releases earlier than Access Manager 3.1 SP2, you were not allowed to configure the Web Server Host name with the port number. SP2 allows you to add a port number.

In the Administration Console, click Devices > Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > Web Servers.
In the Web Server Host Name field, add a port. The following warning message appears:
Select one of the following actions:
- To allow the port, click OK.
- To remove the port, click Cancel.
Update the Access Gateway

The following two scenarios explain how the Access Gateway rewrites port names based on the Web Server Host Name requests and how it does not rewrite with the basic configuration.

Scenario 1: Web Server Host Name with a Port Number

In this scenario, the Access Gateway rewrites URLs and host headers based on the configured Web server host name and port number.

For example, if your configuration looks similar to the following:

Web server host name: www.proxy91.com:8181
Web server connect port: 8080 (HTTP)
 
Published DNS name: www.lag.com
Listening Port: 443

Then:

The host header from Access Gateway to the Web server is rewritten as www.proxy91.com:8181
If a page has URLs, the URLs are rewritten as follows:

http://www.proxy91.com:8181 is rewritten as https://www.lag.com https://www.proxy91.com:8181 is rewritten as https://www.lag.com

The following URLs are not rewritten unless you add additional DNS names:
```
http://www.proxy91.com:8080  
https://www.proxy91.com:8080 
http://www.proxy91.com  
https://www.proxy91.com
```

Scenario 2: Web Server Host Name without a Port Number

In this scenario, the Access Gateway rewrites URLs and host headers based on the configured Web server host name.

For example, if your configuration looks similar to the following:

Web server host name: www.proxy91.com 
Web server connect port: 8080 (HTTP) 
Published DNS name: www.lag.com  
Listening Port: 443

Then:

The host header from Access Gateway to the Web server is rewritten as www.proxy91.com.
If a page has URLs, the URLs are rewritten as follows:

http://www.proxy91.com:8080 is rewritten as https://www.lag.com

The following URLs are not rewritten unless you add additional DNS names:
```
https://www.proxy91.com:8080  
http://www.proxy91.com:8181  
https://www.proxy91.com:8181 
http://www.proxy91.com  
https://www.proxy91.com 
```

7.5.9 On The Linux Access Gateway Appliance Default Rewriter Improperly Rewrite Referrer in the HTTP Headers

Rewriting of referer header to the back-end Web server name is nothing but the reverse rewriting. Reverse rewriting is needed to support acceleration of Microsoft Sharepoint, Novell Teaming, and Microsoft Outlook Webaccess application servers.

Reverse rewriting of headers is enabled by the following flags.

By default the Rewrite Inbound Headers option in default profile or word profile is enabled.
You can use Alternative Host Name instead of Forward received host name option in the Web Server Host Name. If you have used forward received host name, then reverse rewriting of referer header does not work.

If the above two flags are enabled, then the Linux Access Gateway does the reverse rewriting of request headers. Change only the DNS Hostname to be that of web server DNS Name, without changing the URL path as those servers check only the Host Header field.