Section 7.5.2, Rewriting Fails on a Page with Numerous HREFs
Section 7.5.3, Links Are Broken Because the Rewriter Sends the Request to the Wrong Proxy Service
Section 7.5.5, Rewriter Does Not Rewrite Content in Files with a Non-Default Extension
Section 7.5.6, An Additional DNS Name without a Scheme Is Not Rewritten
Section 7.5.8, The Access Gateway Rewrites a Host Header with a Port Number
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.
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.
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
and to .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
option is set to and the DNS name of the Web server is specified in the 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.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.
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
> > > > > .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
.If the Web Server does not send any content type for a non-default extension, then configure extension/<file_extension> as the . For example, if the data sent is http://www.myproxy.com/test.mytxt, then you must configure the as extension/mytxt.
The rewriter rewrites URLs based on the port configured for
, 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
> > > > >Add the additional DNS name with the scheme in the
in the following format:scheme://DNS_name
For example:
https://example.com
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.
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
> > .In the
field, add a port. The following warning message appears:Select one of the following actions:
To allow the port, click
.To remove the port, click
.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.
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
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