Since a URL is a universal resource locator I'll call the set of web pages the resource store. This term will also include any dynamic web page generators.
The store is a hierarchy of nodes. The URL is a path through the store from the top down. Each component of the URL path selects the next node in the store. To be nice and general and allow for different kinds of nodes each node will be passed the remainder of the URL's path and can decide for itself how to intepret this remainder. For example a node might be a CGI-BIN script that interprets query parameters. A node might also synthesise part of the store dynamically giving a different interpretation to the remainder of the path than as just a directory path on disk. Figure 8-1 shows the passage of a URL path through the store.
The input to the store is a list of URL path segments as described in the section called URL Syntax. This list is passed in a message to the root node of the store.
Each node inspects the segment list that it receives. If it is empty then the node is expected to return an entity. In the figure this is the file c.html.
If the list is not empty then the node inspects the first segment and chooses another node to send the remainder of the list to. If the node cannot find another node then an error will be reported.
I won't include the ~user syntax that Apache supports.
In general a node could contain some state that is updated by the request. So each of the nodes needs to be a concurrent object in the sense of the section called CML Threads in Chapter 6. Different nodes can operate concurrently so that the store as a whole can handle multiple URLs concurrently. In addition a node could handle more than one request at a time by spawning a new thread for each request. The total number of threads that can be running in the store will be naturally limited by the maximum number of connections that will be allowed. A node may implement some caching for performance.
Each node will be responsible for controlling access to its part of the store. As long as all URL requests are for reading the store and do not update the store then the nodes can operate independently and concurrently. But there might be a node that is the sole representative of a resource that is updated by a request (for example a hit counter). In this case the serial behaviour of the node will synchronise access to the resource. If more than one node can alter a resource, such as a database or the file system, then they will have to cooperate through a lock manager object.