Page Comparison

Overview

The <Path> element is used to apply content rules settings to requests containing a specific path segment at a particular point in the complete path.

Path matching can be nested, and embedding specifying multiple path segments in a single element is also allowed to simplify authoring heavily nested rules. However, path segments in between matching matched portions cannot be skipped, except by using the <PathRegex> element instead.

...

Finally, do not attempt to use a <Path> element with only a "/" character to indicate the root of a virtual host. It will be ignored, and your log will contain a warning. Put any settings that apply to a an entire virtual host in the parent <Host> element.

Reference

Attributes

Content Specifiers

Content Settings

The element supports a large number of XML attributes corresponding to request mapper properties are used.the content settings supported by the SP:

Child Elements

Access Control 

...

Nested Content Specifiers

...

Example

The example below demonstrates a couple of different syntaxes, but note that the lack of any settings applied to the "secure" path at the root implies that the nested element could just as easily have been specified as "secure/create/new/class" with the same meaning.

<RequestMapper type="Native">
    <RequestMap applicationId="default">
        <Host name="sp.example.org">
            <!-- Example of a single nested path segment -->
            <Path name="secure">
  
                 <!-- Example of a multiple path segments separated by slashes -->
                    <Path name="/create/new/class" authType="shibboleth" requireSession="true">
   
                        <AccessControl><NOT><Rule require="affiliation">student</Rule></NOT></AccessControl>
   
                </Path>
            </Path>
        </Host>
    </RequestMap>
</RequestMapper>