When configured, an SWP scans HTML data, and rewrites HTML URLs. The SWP compares the URLs embedded in the HTML data to a list of URLs listed in the SWP properties file. See Table 14-2.
If an SWP encounters a match in the HTML response data with a URL specified in the properties file, it rewrites the URL to be compliant with the SWP format.
For example, assume that the “Sybase” application was configured to proxy the following two URLs: http://www.sybase.com/ and http://my.sybase.com/. If the HTTP request, http://swp-server:9008/webproxy/proxy/Sybase/0/webpage.html returned an HTML response containing a link to http://my.sybase.com (for example, within an <Anchor> tag), the SWP rewrites the link to http://swp-server:9008/webproxy/proxy/Sybase/1/ where “1” refers to the index of the URL to which the link should proxy—in this case, http://my.sybase.com.
This is all transparent to the end user, except that the added use of CPU cycles can noticeably degrade response time. If an application uses only relative URLs, the parsing mechanism may not be necessary, and can be disabled. Test your applications after disabling parsing to ensure that the application contains only relative URLs. To disable parsing, see Table 14-2, the Options.appname property.
When comparing URLs embedded in HTML documents to the URLs configured in the properties file, an SWP searches for the longest match first. This allows the rewriting script to rewrite related URLs simultaneously. However, the mechanism for searching, comparing, and rewriting URLs is CPU-intensive compared to an SWP configuration that does not rewrite embedded URLs. Be aware of the additional processing required for rewriting, and ensure that your infrastructure can handle the additional load.
