Web Site Rule Documents
Web Site Rule documents help administrators maintain their Web sites by providing a consistent navigation scheme and allowing relocation or reorganization without losing existing links.
After the Web Site document has been created, Web Site Rule documents can be added.
Creating Web Site Rule Documents
To create a Web Site Rule document, follow these steps:
1. | From the Configuration tab in the Administrator client, expand the Web section and click the Internet Sites view. |
2. | Open the Web Site document to which you want to add a rule. |
3. | Click the Web Site button and select Create Rule. |
4. | Fill in the fields as described in the following sections and than click the Save & Close button. |
Each Web Site Rule document has three constant fields: Description, Type of Rule, and Incoming URL Pattern. All other fields are based on the type of rule selected, as described in later sections.
Description is the first field on any rule, and is information designers may want to add for this specific rule. It does not appear in the view and is used for documentation purposes only.
Type of Rule is the next field, which is described in detail in later sections. First let's look at the third constant field.
Each Web Site Rule document has a field called Incoming URL Pattern. URL Pattern is a format or mask that is used to describe the URLs that will be affected by this rule. Before you continue creating Web Site Rule documents, you need to understand how the HTTP task manages URLs. As a security precaution, the Domino 6 HTTP task normalizes an incoming URL against an extensive, predefined set of URL filtering and validation procedures with the intent to reduce all URLs to a safe form before passing them to an application for processing. After a URL is normalized, the Web Site rules are applied.
The component parts of a URL are
http://<host>/<path>?<query>
Only the URL path component (the beginning slash is considered a part of the path) is used for pattern matching and the query is saved to be used by the application. The Incoming URL Pattern field should never include a hostname or query string, is not case-sensitive, and can contain the wildcard character *. Examples of Incoming URL pattern matching are shown in Table 15.2
| Incoming URL Pattern | Matches |
|---|---|
| /myplace/*.nsf | /myplace/personal.nsf |
| /myplace/professional.nsf | |
| /myplace/*professional | This will match any pattern that starts with myplace and ends in professional. |
| /myplace/professional | |
| /myplace/documents/professional |
The second constant field is Type of Rule and there are four types of Web Site Rule documents:
Substitution
Redirection
Directory
HTTP Response Header
When you create more than one type of Web Site Rule document per Web Site document, they are evaluated in the above listed order. Rules are a management function and not a security feature. When protecting resources, protect the resource itself—do not use rules.
 | Pay close attention to understanding Web Site Rule documents, especially the four different types, while preparing for the exam. |
To select the type of rule, click on the drop-down in the Type of Rule field and select the type of rule you want to apply (shown in Figure 15.5) to this Web Site document.
The following sections explain each of the Web Site Rule document types.
Substitution Web Site Rule Documents
Use Substitution Web Site Rule documents when you need to replace parts of an incoming path with new strings. For example, say that your company wants to move an application from the Products subdirectory to Catalog. There are many links referencing Products in the application and it would be too time-consuming to rewrite them. The solution is to write a Substitution rule with the Incoming URL pattern field set to /Products/* and the Replacement pattern set to /Catalog/*. These rules apply to the pattern fields:
Replacement patterns may use the wildcard character *.
Replacement patterns may contain the query string (even though they are not allowed in the incoming pattern), which overrides the query string in the original URL.
If the wildcard character * is not specified in the Incoming URL pattern field and the Replacement pattern field, HTTP will automatically append /* to the pattern.
Redirection Web Site Rule Documents
Use this type of document when you want to redirect an incoming URL to another URL. There are two kinds of redirection rules:
External— Used when the location has changed and you want the new URL to display in the browser. Also used when the Web site has moved and you want to allow existing links and bookmarks to keep working, yet new bookmarks will point to the new URL.
Internal— Used when the location has changed and you do not want the new URL to display in the browser. These are similar to Substitution rules, except Redirection rules can be nested, and redirection does not require a wildcard, so exact matches can be forced on the URL path.
These rules define the kind of redirection pattern:
External Redirect URL patterns must begin with the protocol.
Internal Redirect URL patterns must begin with /.
Redirect patterns may use the wildcard character *, but it is not required.
Directory Web Site Rule Documents
When a Domino 6 Web Server is initially created, three resource directories also are created. When the Web server first starts up, the following resource directories are mapped by internal directory rules and automatically defined on the Configuration tab in the Web Site document:
If the preceding elements are not stored in the default directories, this Type of Rule redirects the incoming URL to the specified Target server directory. The URL pattern must match the incoming URL pattern and also have the proper Access Level as defined in this rule. Read is selected for HTML and Icon directories and Execute is selected for CGI directories. You cannot map other resources, Domino databases, or Java servlets with Directory rules.
HTTP Response Header Web Site Rule Documents
This rule differs from the others in that it is applied to outgoing responses just before HTTP transmits to the browser. By contrast, the first three rules apply to the incoming request before it is passed to the application.
One use of the Response Header rule is to improve performance of browser caching. Caching headers are
Last-Modified header— Indicates when the resource used to generate a response was last changed.
Expires header— Tells browser when the resource is expected to change.
Cache-Control header— Has two options that Domino generates to provide instructions to the browser: “no-cache” and “private.”
Response rules are also used to create your own headers. For example, if a 401 HTTP response code was returned for unauthorized access, you could create a custom error message that read “Sorry, you are not authorized to access this application. Please contact the Support team for help.”
Response rules also differ from the other three in that they have to match the HTTP response status code as well as the URL pattern. As stated earlier, a 401 HTTP code is returned for unauthorized access; a 200 HTTP code is returned if the request has succeeded. These status codes are defined in RFC 2616.