The patterns-Language

The language of the patterns configuration file has been designed for specifying so-called HTTP-request-patterns, against which incoming requests are matched. This involves the examinitation and comparison of characteristical parts of the request. The patterns-language also allows simple selection constructs (if-then-else). Figure 2.16 shows a structural representation of this file's format. A complete definition of its underlying W3C XML Schema can be found in the appendix.

The main elements allowed by the W3C Schema definition of the patterns-language are defined as follows:

patterns

: This element is the root element of the patterns configuration file. It has no attribute and contains a sequence of pattern-elements (see figure 2.15).

**Figure 2.15:** W3C XML Schema of the patterns-element
$\begin{figure} \begin{small} \begin{verbatim} <xs:element name=''patterns''... ... </xs:complexType> </xs:element>\end{verbatim} \end{small} \end{figure}$

pattern

: The attributes of this element contain information about the host name and the port of the web server, which are compared to the corresponding values of the client's HTTP-request in the pattern-matching process. Wildcards for these attributes that match every host name and every port are ''*'' and ''-1'', respectively. The

pattern

-element consists of a sequence of

path

-elements, which provide further examination (and comparison) of the HTTP-request (see 2.17).

**Figure 2.16:** Structure of the patterns configuration file

**Figure 2.17:** W3C XML Schema of the pattern-element
$\begin{figure} \begin{small} \begin{verbatim} <xs:complexType name=''patter... ...efault=''80''/> </xs:complexType>\end{verbatim} \end{small} \end{figure}$

path

: The meaning and usage of the attributes of the

path

-element are similar to the ones in the

pattern

-element, except that this time - instead of the host name - the path of the requested URI is compared to the match-attribute of the

path

-element. Additionally, it provides a second (optional) attribute, named compare, which defines the type of string-comparison that should be used when trying to match the path of the requested URI to the element's match-attribute. The

path

-element has either one child - the

action

-element (see 2.19), or it may contain a sequence of

-elements followed by a closing

else

(see figure 2.21).

action

: This element (of type applySequence, see figure 2.19) contains a sequence of transformation-rules and -rule-groups (or their names, respectively) that should be applied to an HTTP-response after host name, port and URI-path have successfully been matched against the corresponding values of the pattern. This sequence is implemented as a set of text-elements, named

applyGroup

and

applyRuleGroup

, respectively (see figure 2.19). Possible modifications of the header fields (of the forwarded HTTP-request) may be specified before (child-element

setRequestHeaderField

) the definition of this so-called applySsequence . Alternatively - instead of a sequence of rule-references - the

action

-element may only consist of a

redirect

-element (see 2.20). This is used for delegating an HTTP-request to a different location (Note: This new location is then also compared to the available request-patterns, i.e. it will be handled in the same way as a common client-request. The maximum count of consecutive redirections is limited by three.).

**Figure 2.18:** W3C XML Schema of the path-element
$\begin{figure} \begin{small} \begin{verbatim} <xs:complexType name=''path''... ...lt=''equals''/> </xs:complexType>\end{verbatim} \end{small} \end{figure}$

**Figure 2.19:** W3C XML Schema of the action-(type applySequence)
$\begin{figure} \begin{small} \begin{verbatim} <xs:complexType name=''applyS... ... </xs:sequence> </xs:complexType>\end{verbatim} \end{small} \end{figure}$

**Figure 2.20:** W3C XML Schema of the redirect-element
$\begin{figure} \begin{small} \begin{verbatim} <xs:complexType name=''redire... ...=''required''/> </xs:complexType>\end{verbatim} \end{small} \end{figure}$

then

and

else

: The

-element, allows it to specify particular actions for request-URIs with equal host- and pathnames, depending on the values of certain header fields and/or URI-parameters. These fields are compared with the help of the elements

headerField

and

urlParameter

, that consist of a name- and a value-attribute and an optional one (compare), responsible for the type of string-comparison (allowed types of comparison are: equals, startsWith, endsWith, contains, matches and containsRegExp) (see figure 2.21). The

then

-element comes into action, when the values in the if-clause (i.e. particular header fields or parameters of the request-URI) have successfully matched. This element - as well as the

else

-element and the body of the

-element - is of the same type as the

action

-element (applySequence, see figure 2.19). 2.19

**Figure 2.21:** W3C XML Schema of the if-element
$\begin{figure} \begin{small} \begin{verbatim} <xs:complexType name=''if''> ... ... </xs:sequence> </xs:complexType>\end{verbatim} \end{small} \end{figure}$

root 2006-05-22