7.5 Rewriter Issues

7.5.1 Discovering the Issue

To isolate a rewriter issue:

  1. 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.

  2. Access the page from Access Manager, view the source, and copy it to a text file.

  3. 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:

  1. In the Administration Console, click Devices > Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > HTML Rewriting.

  2. 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,

  1. In the Administration Console, click Devices > Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > HTML Rewriting.

  2. 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.

  1. In the Administration Console, click Devices > Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > Web Servers.

  2. In the Web Server Host Name field, add a port. The following warning message appears:

  3. Select one of the following actions:

    • To allow the port, click OK.

    • To remove the port, click Cancel.

  4. 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