Motivation

There are several ways to "interpret" a REQUEST_URI to get at a piece of data that should be returned to the client. In Webware it amounts to finding a piece of code, called a Servlet, that knows what to do with whatever bits of data have been dumped into a Request object to create an appropriately formed Response object representing the Resource. More than one Servlet is often involved in interpreting a request.

direct filesystem mapping

with ExtraPathInfo

regex mapping, like mod_rewrite

Ant-style FileSets/FileMappers

http://jakarta.apache.org/ant/manual/index.html

This may be a filesytem-centric strategy, but it provides a very simple pattern language that is suitable for many purposes, including Webware's current default strategy.

It could be also be used to replace "ExtensionsToIgnore" and friends with a richer selection language.

-- TerrelShumway - 29 Apr 2002

flat text file explicitly specifying a complete map

XPath expressions

XML file

XML instance is a tree-shaped hierarchy of typed containers, which we can use to represent a mapping of URI space onto Webware entities. URISpace has the same characterisitics; it's tree-shaped, hierarchical, and we can use the typing of containers to hold metadata about parts of URI space or bits of config/metadata that can be passed to the Webware entity controlling that part. See, as a really nice example, Mark Nottingham's URISpace 1.0 W3C Note: http://www.w3.org/TR/urispace

URISpace can be used to model a great variety of types of config file, including web or web app servers. Mark's note includes the following example:

<?xml version="1.0" ?>
<urispace xmlns='http://www.w3.org/2000/urispace'
          xmlns:urispace='http://www.w3.org/2000/urispace'
          xmlns:conf='http://www.example.org/server-config'
          xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
    <conf:docroot>/usr/httpd/html</conf:docroot>
    <!-- default doc root -->
    <path match="images">
        <conf:ttl>3600</conf:ttl>
        <!-- set a cache-control: max-age -->
        <conf:auth>basic</conf:auth>
        <!-- authenticate users -->
        <conf:authDB>/usr/httpd/users.db</conf:authDB>
        <scheme match="https">
            <conf:authenticate>off</conf:authenticate>
            <!-- unless they're using SSL -->
        </scheme>
    </path>
    <path match="cgi-bin">
        <!-- cgi directory -->
        <conf:docroot>/usr/httpd/cgi-bin</conf:docroot>
        <conf:execCGI />
    </path>
    <path match="local">
        <!-- deny non-local address -->
        <conf:denyAccess />
        <conf:match type="clientaddress" value="#allowedList">
            <!-- point to a container -->
            <conf:denyAccess urispace:op="clear" />
        </conf:match>
    </path>
    <rdf:Bag ID="allowedList">
        <!-- define a Bag for access ctrl -->
        <rdf:li>192.168.1.0/24</rdf:li>
        <rdf:li>172.16.0.0/16</rdf:li>
        <rdf:li>10.0.0.0/12</rdf:li>
    </rdf:Bag>
</urispace>

This approach has a few benefits: 1) XML aware editors and tools are growing in number and variety; 2) XML really does map nicely onto the problem domain (i.e,. mapping two hierarchical spaces to each other); 3) the config parser is just another XML application, pretty trivial to code; 4) this vocabulary gives a lot of freedom and flexibility; 5) the concrete improvements to the actual URI dereferencing algorithm(s) is separable from the way we represent the mapping it instantiates; 6) URISpace vocabulary seems to fit nicely with the MVC container-controller principle in ManagingTheURISpace.

Web.xml

The Java Servlet Spec uses a file $APP_HOME/__WEB_INF__/web.xml to configure a web application (Context in webware speak). Part of this file is dedicated to describing the servlets included in the app, and a mapping of which URI paths are handled by which servlet. (Again, very good MVC style.)

An example: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/appdev/web.xml.txt

The URISpace XML file described above is a much more general extension of this.

(Sun seems pretty sticky about publishing the spec, but you can get it here: http://www.jcp.org/aboutJava/communityprocess/final/jsr053/ )

-- TerrelShumway - 29 Apr 2002

Requirements

The main purpose of a URI Mapper is to make all of these strategies possible and interchangable without a lot of pain. Furthermore, different strategies are appropriate for different paths in the URI space.