Flexible Resource Resolution

Status: DRAFT
Created: 25. November 2008
Author: fmeschbe
JIRA: SLING-249
References: http://markmail.org/message/cibaddpdfk2jwm7p

Introduction

Currently the resource resolver has a limited set of options to resolve incoming requests to resources and to map resource paths to paths to be used in links in the response:

• Vanity URLs – replace requested path with different path
• URL Mappings – replace path prefixes with different prefixes
• Regular Expressions – regular expressions to resolve and map paths
• VanityPath – property set to an absolute path matched against URL

To implement SLING-249 I initially proposed to add another resolution and mapping option:

• VirtualHost – add path prefix based on Host: header (my proposal)

After an internal discussion I proposed a modified implementation, which drops the existing configuration in favor of full flexibiliy on all resources, by allowing a sling:vanityPath to specify a relative or absolute path or even an URL. Absolute paths and URLs would be used to resolve incoming requests to different locations in the resource tree.

Roy Fielding noted, that allowing any content node to define an absolute entry point for resource resolution would be an open door to bypass delegated security and would also become unmanegeable over time. In his message he proposed a slightly different approach, by specifying a location in the repository, where such root entries would be configured. On the content level, only local aliases are allowed to be defined.

This page is about trying to write up the fine print in this proposal and also document the actual implementation.

Goals

• Separate concerns for root level mappings and local aliases. This allows administrators to define root level mappings preventing regular authors from tampering and allows page authors to define aliases for their pages.
• Allow providing different content trees for different virtual hosts while at the same time allowing to share recources amongst all virtual hosts.
• Provide funtionality to externally and internally redirect. External redirects are implemented by sending a 302/FOUND response with a different Location to the client. Internal redirects are handled by just resolving a different actual resource path.
• Allow authors to define alias names for their resources which may be used in URLs.

Properties

When dealing with the new resource resolution we have a number of properties influencing the process:

• sling:redirect – This property when set on a node in the /etc/map tree (see below) causes a redirect response to be sent to the client, which causes the client to send in a new request with the modified location. The value of this property is applied to the actual request and sent back as the value of Location response header.
• sling:internalRedirect – This property when set on a node in the /etc/map tree (see below) causes the current path to be modified internally to continue with resource resoltion.
• sling:alias – The property may be set on any resource to indicate an alias name for the resource. For example the resource /content/visitors may have the sling:alias property set to besucher allowing the resource to be addressed in an URL as /content/besucher.

Node Types