Sun ONE Portal Server 3.0 Rewriter Configuration and Management Guide

Like this article? We recommend

Capacity Planning for Internet Services

Learn More Buy

Like this article? We recommend

Like this article? We recommend 

Capacity Planning for Internet Services

Learn More Buy

Rewriting JavaScript Content

Because JavaScript is a programming language, there can be any number of ways to represent the same functional result. The trick is that if the result contains a URL, the gateway will need to understand that fact. The reasoning is exactly the same as the reason for rewriting HTML: If there is some URL-handling performed using JavaScript content, then the request would still need to be sent back to the gateway component rather than attempting to directly contact the internal web application server.

For many Sun ONE Portal Server gateway administrators, rewriting JavaScript content will be the most difficult task deploying and maintaining a secure Portal Server installation. The randomness at which URLs can occur throughout scripted code contributes to the difficulty, and the fact that JavaScript content is intertwined with HTML SPEC 4.0 adds to the challenge.

Areas where JavaScript content may need to be rewritten include the obvious SCRIPT elements, event handlers within HTML tags, and imported JavaScript content. Specific things to look for are references to window and document object methods, events, and properties that may affect or refer to URLs. Otherwise, obvious areas may include variable assignments, function parameters, and JavaScript object arrays.

Having a good understanding of how to write JavaScript content will be very helpful when trying to mine out URLs contained in it. While the introduction to, and usage of JavaScript content, is beyond the scope of this guide, the JavaScript objects and methods that you will need to be concerned with, as they relate to the rewriter, will be covered in detail. The browser implementation of the document object model is different for different browsers, and each browser offers JavaScript content its own set of capabilities. Those that are for the most part common between the Internet Explorer and Netscape Navigator browsers are discussed in this guide.

Web Browser Document Object Properties

Document object properties are generally manipulated through a JavaScript assignment statement. In most cases, the full object path will be on the left side of the assignment operator, and a raw URL will be on the right side of the assignment operator.

With that known, you can now differentiate when a rule should be added to the Rewrite JavaScript Variables in URLs section of the gateway profile or the Rewrite JavaScript Variables Function section. Generally speaking, when the right side of a variable assignment is a raw URL and the left side is a document object property, then the full object path should be added to the Rewrite JavaScript Variables in URLs section of the gateway profile. While assignments of this type can be handled by either section, having the server rewrite the URL will save client compute resources required to render and/or use the page.

For example, consider the following JavaScript assignment:

document.location.href = "http://www.iplanet.com";

The right side is clearly a raw URL, so the rule to be added to the Rewrite JavaScript Variables in URLs section is: document.location.href

Consider the following assignment:

document.location.href=newURL;

There are two options to handle the rewriting of this statement. The first is to see if newURL can be rewritten elsewhere so that document.location.href would not have to be added to the gateway profile for this particular instance. The second is to add document.location.href to the Rewrite JavaScript Variables Function section of the gateway profile. As mentioned earlier, adding this rule will result in the entire right side being wrapped in an iplanet function call.

document.location.href=iplanet(newURL);

The iplanet function will evaluate its parameter and return a rewritten URL using the browser JavaScript engine. The iplanet function body will also be inserted within the SCRIPT tags. As of SP3 Hot Patch 3, adding a rule to this section of the gateway profile to handle a JavaScript assignment called from an event handler will result in the iplanet function body being defined inside of the HTML tag itself. Thus, the following code cannot be rewritten in versions before SP4 Hot Patch 1.

<INPUT TYPE="BUTTON" NAME="button" VALUE="Click"
onClick="document.location.href=newURL;">

This particular scenario will only arise if the newURL variable has been defined within a script tag in the document HEAD, due to JavaScript variable scoping. However, that also means that newURL must have an assignment defined in the HEAD element that might be rewritten there.

The following are some browser object properties that can contain URLs:

• document.location.href—Used to change the URL for the current page.

• document.location.path—Used as part of a relative URL.

• document.location.protocol—Used to form a URL.

• document.location.host—Used to form a URL.

• document.referrer—Used for the URL of the document which referred to the current one.

• document.URL—Used for the URL of the current document.

Because of the JavaScript object scoping, each of the proceeding properties can also have window prepended to the full property path. The window object itself also has several event handlers that can contain additional JavaScript content. Two of the more well-used window object events are onLoad and onUnload. window events are often located in the BODY tag of the HTML document and execute when the page is first being rendered (as in the case of the onLoad event). Frames can also use onLoad and onUnload events.

When referring to specific frames or other objects in the DOM hierarchy, the object path may differ, which would require either an additional rule or a wildcard rule, if possible. Neither window.location.href nor parent.location.href would be matched by the location.href rule. However using SP3 Hot Patch 3, if the right side is a raw URL, an entry such as *.location.href can be added to the Rewrite JavaScript Variables in URLs section of the gateway profile that will handle both cases with a single rule.

Web Browser Document Object Methods

There is not any one specific way in which to rewrite browser document object method calls that contain URLs. The rule syntax and appropriate section to be considered in the gateway profile depends on the method's parameter(s) and its semantics. For example, the window.open method takes several parameters, but they must be in a specific order, and all of them start with a URL as the first parameter. If the URL is a raw URL, then the function name can be added to the Rewrite JavaScript Function Parameters section of the gateway profile.

The syntax for a rule in this section is funcName:y, where funcName is the function name that is followed by a colon separator and either by a y or a comma. A comma is used to signify multiple parameters, and a y is used to tell the gateway that a particular parameter requires rewriting. This may be easier to understand in practice. Consider a call to window.open in the following example:

<HTML>
<HEAD>
<SCRIPT>
function myWin() {
window.open('/channels/stocks_channel.html','Stocks',
'width=300,height=250,directories=no,location=no,menubar=no,
scrollbars=yes,status=no,toolbar=no,resizable=yes');
}
 </SCRIPT>
</HEAD>
<BODY onLoad="myWin()";
</BODY>
</HTML>

After this document loads, another with stock information will automatically open. The onLoad attribute could be listed in the Rewrite HTML Attributes Containing JavaScript section of the gateway profile, but it is not necessary in this case because the right side of the assignment operator is not a raw URL, but instead, a function call. Inside the body of the myWin function, however, there is a call to the browser document object method window.open, whose first parameter is a relative URL. So, the following rule would be added to the Rewrite JavaScript Function Parameters section of the gateway profile: window.open:y

This particular rule has already been added to the gateway profile, out-of-box, but it is referred to, in this case, to explain when and how to add a rule to this particular section of the gateway profile. If the content is passed through the gateway that contains a call to window.open, where the first parameter is not a raw URL, then the window.open:y method would have to be moved from the default section of the gateway profile to the Rewrite JavaScript Function Parameters Function section.

Consider the example:

<HTML>
<HEAD>
<SCRIPT>
function myWin() {
myURL = '/channels/stocks_channel.html'; window.open(myURL,'Stocks',
'width=300,height=250,directories=no,location=no,
menubar=no,scrollbars=yes,status=no,toolbar=no,resizable=yes'); }
 
</SCRIPT>
</HEAD>
<BODY onLoad="myWin()";>
</BODY>
</HTML>

There are two ways to rewrite the page so that it will function correctly. The first, which has been discussed already, is to add myURL to the Rewrite JavaScript Variables in URLs section of the gateway profile. The second is to move window.open:y from the Rewrite JavaScript Function Parameters section of the gateway profile to the Rewrite JavaScript Function Parameters Function section. Although the name may be a bit confusing, this latter profile section works similarly to the Rewrite JavaScript Variables Function section, in that an iplanet function is defined and the variable, or parameter in this case, is then wrapped within an iplanet function call. However, because window.open and other browser object methods are often called directly by event handlers, it is better in this case to rewrite only the myURL variable to avoid the problem where the iplanet function body is inserted in the HTML tag itself, unless you have SP4 Hot Patch 1 installed.

The following are some other browser object methods that can contain URLs:

• document.assign—Sets the document.location.href property value.

• document.write—Used for dynamically creating content using the client computing resources.

• document.writeln—Used in the same manner as document.write with the added benefit of a line break.

JavaScript Object Arrays

One other way JavaScript code is used to manipulate URLs is through the use of the default JavaScript object arrays. These provide accessor functionality to the JavaScript content so that attribute values can be changed dynamically after the page is rendered in the browser. Object arrays can be used in a variety of ways, including a mouseOver for image buttons, preloading content such as images that will be used in a JavaScript animation, or FORM field changes or checks.

Most of the arrays containing URLs that you may need to address are anchors, Applets, forms, frames, images, and links. The syntax of the JavaScript object array references includes the full object path, array name, index value, and attribute to change.

The following is an example:

function preLoadImages() {
 this[1] = new Image();
 this[1].src = "image1.gif";
 this[2] = new Image();
 this[2].src = "image2.gif";
}
if (document.images) {
 preLoadImages();
}

This example may force the page to take a bit longer to download because all of the images are fetched first, even if they are not initially displayed. This is common practice for mouseOver events or animations where the usability of the page depends on quick retrieval (in this case, from the browser cache) of the images. The result of this code running is that the image object will be populated and can be accessed using the JavaScript document.images[index].src object array. It is important to note that because the rewriter operates using regular expressions, brackets have special meaning and cannot be used in the rule entries.

As previously mentioned, SP3 Hot Patch 3 allows wildcards in the Rewrite JavaScript Variables in URLs section of the gateway profile to correctly handle JavaScript object array references. Thus, the correct rule for the above example would be: this*.src

Be sure to include the attribute name SRC in the rule to avoid possible problems with the image constructor attempting to be rewritten or similar problems if the image names, or some other attribute value, were also initialized by the preLoadImages function. Using wildcards can be even more beneficial when the index is created dynamically.

The following is an example:

<HTML>
<HEAD>
<TITLE>Test for rewriting JavaScript Arrays - RFE #4504371 </TITLE>
<SCRIPT>
<!--
 function depress(imgNum){
  if (imgNum == 1) {
   document.images["IMG"+imgNum].src = "../../img/Back_lit.gif";
   liftUp(2);
  }
  else if (imgNum == 2) {
   document.images["IMG"+imgNum].src = "../../img/Forward_lit.gif";
   liftUp(1);
  }
 }

 function liftUp(imgNum) {
  if (imgNum == 1) {
   document.images["IMG"+imgNum].src = "../../img/Back.gif";
  }
  else if (imgNum == 2) {
   document.images["IMG"+imgNum].src = "../../img/Forward.gif";
  }
}
//-->
</SCRIPT>
 </HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
<A HREF="#" onClick="depress(1);"><IMG SRC="../../img/Back.gif"
NAME="IMG1" BORDER="0"></A>
<A HREF="#" onClick="depress(2);"><IMG SRC="../../img/Forward.gif" 
NAME="IMG2" BORDER="0"></A>
</BODY>
</HTML>

Here again, the only rule required to rewrite the JavaScript images array reference is: document.images*.src

The *.src can also be used to reduce rule clutter and maintain performance by limiting the number of rules that the gateway has to compare when rewriting JavaScript content. The leading period is still included to avoid accidentally rewriting of other assignments whose left side ends in SRC. Using a wildcard here, as in most cases, can be just as dangerous as it is beneficial. A rule of thumb is that specificity limits unintended consequence at the expense of flexibility.

Specialized JavaScript Variables

There are a few built-in JavaScript variables for which a relative URL is required, rather than translating its value into an absolute URL. location.pathname for instance should only specify the path portion of a URL. Normally, if a page containing location.pathname is accessed through the gateway, its value would incorrectly contain 'redirect/', in addition to the protocol and server where the content originated from instead of just the relative path.

Starting in SP3 Hot Patch 1, there is a special section of the gateway profile, called Rewrite JavaScript System Variables Function, that is set aside for special variables. Similar to how the iplanet function is used to dynamically rewrite URLs using the browser's JavaScipt engine, another function called iplanet_pathname is used to do the same thing for built-in JavaScript variables whose values need to remain relative URLs.

The following is an example:

<HTML>
<HEAD>
<TITLE>JavaScript Test</TITLE>
<SCRIPT LANGUAGE="JAVASCRIPT">
var pathname = window.location.pathname

</SCRIPT>
</HEAD>
<BODY>
<P>This page tests the windows.location.pathname system variable.</P>
</BODY>
</HTML>

The above example will be rewritten as:

<HTML>
<HEAD>
<TITLE>JavaScript Test</TITLE>
<SCRIPT LANGUAGE="JAVASCRIPT">
 var pathname = iplanet_pathname(window.location.pathname) 
function iplanet_pathname(thePath) { 
  newPath = thePath.substr( thePath.indexOf( "/", thePath.lastIndexOf("://") + 3 ))
  return newPath
}
</SCRIPT>
</HEAD>
<BODY>
   <P>This page tests the windows.location.pathname system variable.</P>
</BODY>
</HTML>

Entries in this section of the gateway profile will likely be sparse, but this section can be useful if the content defines its own object rather than using the window object.

The following is an example:

<HTML>
<HEAD>
<SCRIPT>
function aFunc(myPage){
 var URL=myPage.location.pathname; // contains full URL w/o protocol
 var lowerURL = URL.substring(0, URL.toLowerCase().indexOf(".html")) + 
".html";
 return lowerURL;
}
 var newURL = aFunc(self) + "/cgi-bin/aCGI?val1=foo&val2=bar";
</SCRIPT>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
</BODY>
</HTML>

In this case, myPage.location.pathname would have to be added to the Rewrite JavaScript System Variables Function section for the expected behavior to occur.

Nested JavaScript Code

Nesting JavaScript code makes the mining out of URLs a bit more difficult and adding the correct rules a bit more challenging. For instance, the window object method setTimeout takes an expression as a first parameter that can itself be a JavaScript function call.

The following is an example:

<HTML>
<HEAD>
<SCRIPT>
function statusMsg(msgURL) {
 window.status = msgURL;
}

</SCRIPT>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
<SCRIPT>
window.setTimeout("statusMsg('http://www.iplanet.com')", 1000);
</SCRIPT>
</BODY>
</HTML>

Assume that you could not work around this by rewriting the window.status assignment by adding it to the Rewrite JavaScript Variables Function section of the gateway profile. Instead, you are able only to rewrite the window.setTimeout statement for the application to work correctly.

In this case, two things have to be done. First, the rewriter needs to know that the first parameter of the window.setTimeout function call contains JavaScript content. So, the window.setTimeout:y rule must be added to the Rewrite JavaScript Function Parameters in JavaScript section of the gateway profile. Secondly, the rewriter needs to know that the first parameter of the statusMsg function is a raw URL, so the statusMsg:y rule must be added to the Rewrite JavaScript Function Parameters section.

Consider the following example:

<HTML>
<HEAD>
<SCRIPT>
var curURL = 'http://www.iplanet.com';
function statusMsg(msgURL) {
 window.status = msgURL;
}

</SCRIPT>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
<SCRIPT>
window.setTimeout("statusMsg(curURL)", 1000);
</SCRIPT>
</BODY>
</HTML>

The setTimeout statement can only be rewritten by adding statusMsg:y to the Rewrite JavaScript Function Parameters Function section of the gateway profile, starting in the SP4 Hot Patch 1 release. Otherwise, the only way to rewrite this example correctly is to rewrite the curURL assignment statement.

Event Handlers

Event handlers are a special kind of HTML tag attribute whose value can contain JavaScript content. Most event handlers begin with the letters on and are initiated by different user actions, such as mouse events or keyboard activity. Many event handlers have already been added to the gateway profile, out-of-box, and they can be seen by looking at the Rewrite HTML Attributes Containing JavaScript section of the gateway profile. Basically, by adding a value to this section, it must be a valid HTML attribute whose value contains JavaScript content. The value of the attribute is then translated by the gateway as JavaScript content.

Imported JavaScript Files

Rewriting imported JavaScript files follows the same basic principles as rewriting inserted JavaScript content, except that relative URLs may not be handled correctly. Because the Netscape Navigator browser does not send an HTTP Referrer header in the imported JavaScript request, there is no way for the rewriter to determine the exact URL to be used as the base.

Consider the following HTML source:

<HTML>
<HEAD>
<SCRIPT SRC="scripts/test.js"></SCRIPT>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">

</BODY>
</HTML>

Here is the JavaScript source:

imgsrc = "images/test.jpg";

window.open(imgsrc,'test');

If the page was accessed at:

http://www.iplanet.com/importedjs.html

And, if imgsrc had already been added to the gateway profile, then the imgsrc value would be rewritten as:

https://ips-gateway.iplanet.com/http://www.iplanet.com/scripts/images/test.jpg

Instead of:

https://ips-gateway.iplanet.com/http://www.iplanet.com/images/test.jpg

The reason for this is that the SCRIPT SRC attribute value will be rewritten to: https://ips-gateway.iplanet.com/http://www.iplanet.com/scripts/test.js

Without having a Referrer header, this value will be used to resolve the relative links in the imported JavaScript file.

There is currently no fix for this limitation from AOL for the 4.x or 6.x Netscape Navigator browser. However, there is a fix available in SP4 Hot Patch 1 for the Internet Explorer browser that makes use of the Referrer header to resolve the relative links correctly.

imgsrc = "/images/test.jpg"; 
window.open(imgsrc,'test'); 

Imported JavaScript content is used by many web applications to make the page source cleaner and as a way to hide intellectual property contained in the JavaScript content. URLs are not always contained in imported JavaScript content, but it is still a good idea to check. One way to view the imported JavaScript source, without having to dig through the browser cache, is to create your own Web page with links that point to the remote JavaScript file.

The following is an example:

<HTML>
<BODY>
<A HREF="http://www.iplanet.com/scripts/test.js">test.js</A>
</BODY>
</HTML>

Using the Netscape Navigator browser, you can access this page, right-mouse click over the link, and choose Save As. After you have the JavaScript file saved, you can determine what, if anything, will need to be rewritten for the application to work correctly through the gateway. If this is not possible, you can also refer to the iwtGateway log file and look for the actual imported JavaScript content to see if it contains URLs. The ips.debug value needs to be changed from error to message before looking for URLs in the gateway log. For performance reasons, it is not recommended to keep the log level set to message for an extended period of time in a production environment.

Dynamically Created HTML Blocks

One of the features that makes JavaScript programming language so attractive to web application developers is its ability to manipulate multiple windows and frames dynamically using the client JavaScript engine. The functionality is used for navigation purposes, site maps, form handling, and ad generation.

Consider the following example:

<HTML>
<HEAD>
<TITLE>Tests rewriting of dynamically created HTML blocks</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
<SCRIPT>
myWindow = window.open("","myWindow");
mySrc = "<HTML>" +
    "<BODY BGCOLOR=#FFFFFF TEXT=#000000>" +
    "<IMG SRC='/images/logo.gif'>";
self.myWindow.document.write(mySrc);
self.myWindow.document.close();
 
</SCRIPT>
</BODY>
</HTML>

This example essentially demonstrates opening a new window and then creating the source necessary for an image to be displayed in the new window. What sets this example apart from other JavaScript rewriting examples given thus far is that the IMG SRC attribute is created dynamically by the client rather than passing through the gateway, which would normally translate the SRC attribute value. So, the rewriter needs to know that the JavaScript variable mySrc contains HTML content that should be rewritten accordingly.

To do this, the mySrc rule needs to be added to the Rewrite JavaScript Variables in the HTML section of the gateway profile. So, if pop-up windows in your web application are not working correctly or simply coming up blank, it may be due to the fact that there is an HTML block created dynamically using JavaScript code that is not being rewritten correctly.

JavaScript Code Used to Create JavaScript Content

Relatively rare cases to be aware of when rewriting JavaScript content are statements whose right side contains variable initializations that could have a right side that is a URL string literal.

The following is an example:

<HTML>
<HEAD>
<SCRIPT>
tmpURL = "var address = 'http://www.iplanet.com'";
</SCRIPT>
 
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
 
</BODY>
</HTML>

In this particular case, tmpURL becomes a string object which contains var address = 'http://www.iplanet.com'. This syntax is useful in multi-windowing applications where JavaScript content in the parent is responsible for writing JavaScript content in the child window as a result of user events. For the URL to be rewritten correctly, a rule address needs to be added to the Rewrite JavaScript Variables in URLs section of the gateway profile, and the tmpURL rule needs to be added to the Rewrite JavaScript Variables in JavaScript section.

JavaScript Code Obfuscators

Obfuscation can come in many forms including scramblers, optimizers, and full-on obfuscation, whose only purpose is to make it difficult for the hacker to pick off publicly available JavaScript source embedded in pages. Usage of JavaScript code obfuscation site-wide in an ASP environment, a business-to-business model, or in a variety of other scenarios may make rewriting difficult, if not impossible, depending on the nature of the JavaScript code and how the code obfuscator works. If the obfuscation is done dynamically, then it probably will not be possible to create static rewriter rules that will predictably rewrite embedded URLs.

Different obfuscators contain different features, but to effectively obfuscate the JavaScript code, function names and variables are typically altered. The same code altered twice may contain different names, while other altered code may contain the same names.

The following is an example of the source for page 1:

<SCRIPT>
text = "hi there";
</SCRIPT>

The following is the source for page 2:

<SCRIPT>
url = "http://www.iplanet.com";
</SCRIPT>

After being run through JavaScript code obfuscation, both pages may look like the following:

<SCRIPT>x002323="hi there";</SCRIPT>

<SCRIPT>x002323="http://www.iplanet.com";</SCRIPT>

If JavaScript code obfuscation is a requirement, then URL references must be extracted from the code for obfuscation and handled a different way such as inserting them in a top level frame or importing the raw JavaScript content containing the URL variables. You can use an obfuscator with configurable code generation in which variables and function names can be mapped.

The following is an example of an obfuscator that maps variables to three-letter codes:

url -> scf

You could then add scf to the appropriate section of the gateway profile.

Best Practices—JavaScript Programming for Use Through the Gateway

You should use the following best practices:

• Do not create variable references with dotted object paths whose right side is not a raw URL, as in the following example:

  this.foo = protocol + server + path + resource;

• Avoid deeply nested JavaScript content.

  The more difficult and spaghetti-like the code is, the harder it is to get it to work through the gateway.

• Use absolute URLs or URLs relative to the content server root in imported JavaScript files.

  This is necessary until the Portal Server is certified for use with the 6.0 browsers and until both of them send a Referrer header when requesting a remote JavaScript file. Inlined JavaScript content can also be used, which does not have this limitation.

• Avoid mixing JavaScript variables with HTML blocks that are created dynamically, as in the following example:

  <HTML>
  <HEAD>
  <TITLE>Tests rewriting of dynamically created HTML blocks</TITLE>
  </HEAD>
  <BODY BGCOLOR="#FFFFFF" TEXT="#000000">
  <SCRIPT>
  var myURL = "http://www.iplanet.com";
  myWindow = window.open("","myWindow");
  mySrc = "<HTML>" +
      "<BODY BGCOLOR=#FFFFFF TEXT=#000000>" +
      "<A HREF='" +
      myURL +
      "'>link</A>";
  self.myWindow.document.write(mySrc);
  self.myWindow.document.close();
   
  </SCRIPT>
  </BODY>
  </HTML>

• Avoid defining URLs using multiple string concatenations or in different locations in the code, as in the following example:

  <SCRIPT>
  url = "http://www.iplanet.com";
  url += "/scripts/gen_form.pl";
  url += "?var1=foo&var2=bar";
  url2 = url + url2;
  </SCIPT>

• Avoid making assumptions about what a URL should look like.

  More specifically, do not assume that in the JavaScript code, a particular URL will be relative in nature.

• Avoid mismatched quotes after assignment statements, as in the following example:

  <HTML>
  <HEAD><TITLE>Test Case for rewriting src tags twice</TITLE></HEAD>
  <SCRIPT LANGUAGE="JavaScript">
   
  lnk = "http://www.iplanet.com"; 
  
  document.write('<img border="0" src="'+lnk+'/images/logo.jpg" 
  alt="ALT"></A><BR>\n')
  document.write('<img border="0" src="/images/logo.jpg" alt="ALT"></A>')
   
  </SCRIPT>
  <BODY>
  </BODY>
  </HTML>

  NOTE

  In the SP4 Hot Patch 1 release, this limitation is resolved in this particular case, but there may be other similar corner cases that will continue to fail to be rewritten correctly.

• Avoid using JavaScript code obfuscation.

• Use standardized naming conventions for URLs throughout the code, and use them in the same context.

  Notice the inconsistent naming conventions in the following two examples.

  The following is in the source for page 1:

  <SCRIPT>
  url = "http://www.iplanet.com"
  </SCRIPT>

  The following is in the source for page 2.

  <SCRIPT>
  tmpURL = "http://www.iplanet.com";
  url = "The URL is" + tmpURL;
  </SCRIPT>

• Do not over-generalize when specifying wildcards in rules, as in the following examples:

  *location
  *src

  NOTE

  The *location wildcard is more generalized than the *.location wildcard.

• Do not attempt to overload JavaScript Function Parameter rules, as in the three rules specified in the Rewrite JavaScript Function Parameters section of the gateway profile.

  openMyWin:,y,,
  openMyWin:y,,y,
  openMyWin:y

  NOTE

  Only the first rule will be matched. The individual function definition should determine how many parameters are passed using the length method, instead of defining multiple functions with the same name in different pages. This would also eliminate the problem with the argument type and the order.

  The following are more examples of overloaded rules:

  menu.addItem(
   new NavBarMenuItem("Info",
  "JavaScript:top.location='http://www.iplanet.com'"));
  menu.addItem(
   new NavBarMenuItem("Info","http://www.iplanet.com"));

  NOTE

  The SP4 Hot Patch 1 release offers a new advanced gateway profile section that handles ambiguous JavaScript function parameters that are either URLs or JavaScript code, as in the example above. For more information, refer to the SP4 Hot Patch 1 release notes that are included with the patch.