...
Tip | ||
---|---|---|
| ||
If you're using Apache, you should consider using the native |
Table of Contents |
---|
General Structure
The XML-based syntax operates against the logical URL requested by the client, and not the physical path or file accessed. This is analagous to the difference between the Apache <Location>
and <Directory>/<Files>
distinction.
...
To see how this works in practice, consider this moderately complex example. No actual content settings are shown, as would be found in a real example, to emphasize the matching process.
Code Block | ||||
---|---|---|---|---|
| ||||
<RequestMap> <!-- A -->
<Host name="sp.example.org"> <!-- B -->
<Path name="/"/> <!-- Do NOT do this, it will be ignored! -->
<Path name="secure"/> <!-- C -->
<Path name="admin"> <!-- D -->
<Path name="secure"/> <!-- E -->
</Path>
<Path name="admin/badexample"/> <!-- Do NOT do this, it will be ignored! -->
<Path name="combined/path"/> <!-- F -->
</Host>
<Host scheme="https" name="internal.example.org"/> <!-- G -->
</RequestMap>
|
...
is equivalent to this:
Code Block | ||||
---|---|---|---|---|
| ||||
<Path name="one">
<Path name="two">
<Path name="three"/>
</Path>
</Path>
|
The requested URL's path portion is divided into segments and processing proceeds by looking for matching segments. As matches are found, the matched segment is discarded and the process descends into the matching element and then the same process is repeated, until no further matches are found.
Warning | ||
---|---|---|
| ||
Is the path matched in a case-insensitive manner? Can it be? What if the underlying web-server / file-system is case insentive? When the request gets mapped into a filesystem resource, it could lead to a authorization bypass if an attacker changes the case of a request. (I would have added this as a comment, but comments appear to be disabled for me). A similar concern would surround other normalisation concepts, such as Unicode normalization and potentially other special filenames (eg. *.aux) on Windows. |
Query Matching
Once the most-specific path match is identified (if any), the final step is to look for child <Query>
elements to match against the decoded query string parameters. Absent such elements, the query string information is NOT used during path matching and ignored.
...