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
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).
W3C XML Schema of the patterns-element
- 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'',
The pattern-element consists of a sequence of path-elements,
which provide further examination (and comparison) of the HTTP-request (see
Structure of the patterns configuration file
W3C XML Schema of the pattern-element
- 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 if-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
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
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.).
W3C XML Schema of the path-element
W3C XML Schema of the action-(type applySequence)
W3C XML Schema of the redirect-element
- if, then and else: The if-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
if-element - is of the same type as the action-element
(applySequence, see figure 2.19).
W3C XML Schema of the if-element