The SP software includes an implementation of the RequestMapper plugin , a plugin interface that combines "native" configuration support specific to certain web servers with a portable mechanism that relies on an XML syntax for applying settings to content and works across all the supported platforms.
A more complete syntax reference to using this mechanism can be found in the Request MapRequestMap topic. This topic will outline how to use it, show some examples, and note some potential mistakes.
| Tip | ||
|---|---|---|
| ||
If you're using Apache, you should consider using use the native |
| Table of Contents |
|---|
General Structure
...
The mapper executes by breaking apart the requested URL into three parts: the host, path, and query. The host portion consists of scheme://authority:port (everything before the slash that starts the path). The path is everything after the host portion up to, but not including, the first '?' character, if any. If a '?' separator exists, the query portion consists of all the decoded parameters found after that point.
Each portion is then matched against the elements inside the <RequestMap> in order to locate the "deepest" (most-specific) matching element, which is then used to derive the content settings to apply to the request.
The structure of the map, as with XML in general, is of a tree, with elements nested inside of other elements in a parent-child relationship. The mapping process walks this tree by evaluating each set of siblings and, when a match is found, descending into the matching element to evaluate its child elements, and so on. The information from the requested URL that matches is "consumed" each time the algorithm descends into a matching element, and only the remaning portion, if any, is available for further matching. Eventually, nothing is left to match against, no child elements remain, or none of them match. At that point, the process stops with the last matched element and it forms the bottom of the tree to use.
...
Note in the example above that none of the <Path> elements contain leading or trailing slash characters. Such characters will be stripped from the configuration and ignored, so they are insignificant.
...
The implementation does not allow siblings to "overlap" in the URL tree, and it will ignore the overlapping element, producing unexpected results. The native log will warn about this during configuration parsing.