| Prev | Chapter 15. Kernel Documentation | Next |
|---|
+ The request processor is the set of procs that responds to every HTTP
request made to the OpenACS. The request processor must authenticate the
connecting user, and make sure that he is authorized to perform the given
request. If these steps succeed, then the request processor must locate the
file that is associated with the specified URL, and serve the content it
-provides to the browser.
+provides to the browser.
pageroot -- Any directory that contains scripts and/or
static files intended to be served in response to HTTP requests. A typical
-OpenACS installation is required to serve files from multiple pageroots. global pageroot
+OpenACS installation is required to serve files from multiple pageroots. global pageroot
(/var/lib/aolserver/servicename/www) -- Files appearing under
this pageroot will be served directly off the base url
-http://www.servicename.com/ package root
+http://www.servicename.com/ package root
(/var/lib/aolserver/servicename/packages) -- Each subdirectory of
the package root is a package. A typical OpenACS installation will have several
-packages. package pageroot
+packages. package pageroot
(/var/lib/aolserver/servicename/packages/package_key/www)
--- This is the pageroot for the package_key package. request environment (ad_conn) -- This is
+-- This is the pageroot for the package_key package. request environment (ad_conn) -- This is
a global namespace containing variables associated with the current
-request. abstract URL -- A URL with no extension that doesn't
-directly correspond to a file in the filesystem. abstract file or abstract path -- A URL
-that has been translated into a file system path (probably by prepending the
+request. abstract URL -- A URL with no extension that doesn't
+directly correspond to a file in the filesystem. abstract file or abstract path -- A URL
+that has been translated into a filesystem path (probably by prepending the
appropriate pageroot), but still doesn't have any extension and so does
-not directly correspond to a file in the filesystem. concrete file or concrete path -- A file
-or path that actually references something in the filesystem. Package Lookup One of the first things the request processor must do is to determine
which package instance a given request references, and based on this
information, which pageroot to use when searching for a file to serve. During
this process the request processor divides the URL into two pieces. The first
@@ -106,20 +43,12 @@
able to figure out which package_id is associated with a
given package_url, and package mountings must be persistent across server
restarts and users must be able to manipulate the mountings on a live site,
-therefore this mapping is stored in the database. Authentication and Authorization Once the request processor has located both the package_id and concrete
+therefore, this mapping is stored in the database. Authentication and Authorization Once the request processor has located both the package_id and concrete
file associated with the request, authentication is performed by the session security system. After authentication has
been performed the user is authorized to have read access for the given
package by the OpenACS 4 Permissions Design.
If authorization succeeds then the request is served, otherwise it is
-aborted. Concrete File Search To actually serve a file, the request processor generates an ordered list
+aborted. Concrete File Search To actually serve a file, the request processor generates an ordered list
of abstract paths and searches each path for a concrete file. The first path
searched is composed of the package pageroot with the extra portion of the
URL appended. The second abstract path consists of the global pageroot with
@@ -130,11 +59,7 @@
directory. Files take precedence over directory listings, so an index file in
the global pageroot will be served instead of a directory listing in the
package pageroot, even though the global pageroot is searched later. If a
-file is found at any of the searched locations then it is served. Virtual URL Handlers If no file is found during the concrete file search, then the request
+file is found at any of the searched locations then it is served. Virtual URL Handlers If no file is found during the concrete file search, then the request
processor searches the filesystem for a virtual url handler
(.vuh) file. This file contains normal Tcl code, and is in
fact handled by the same extension handling procedure that handles .tcl
@@ -149,55 +74,29 @@
special distinction is required between sitewide procs and package specific
procs when using this facility. It is also much less prone to overlap and
confusion than the use of registered procs, especially in an environment with
-many packages installed. The request processor manages the mappings from URL patterns to package
+many packages installed. The request processor manages the mappings from URL patterns to package
instances with the site_nodes data model. Every row in the site_nodes table
represents a fully qualified URL. A package can be mounted on any node in
this data model. When the request processor performs a URL lookup, it
determines which node matches the longest possible prefix of the request URI.
In order to make this lookup operation as fast as possible, the rows in the
site_nodes table are pulled out of the database at server startup, and stored
-in memory. The memory structure used to store the site_nodes mapping is a hash table
+in memory. The memory structure used to store the site_nodes mapping is a hash table
that maps from the fully qualified URL of the node, to the package_id and
package_key of the package instance mounted on the node. A lookup is
performed by starting with the full request URI and successively stripping
off the rightmost path components until a match is reached. This way the time
required to lookup a URL is proportional to the length of the URL, not to the
-number of entries in the mapping. The request environment is managed by the procedure
+number of entries in the mapping. The request environment is managed by the procedure
ad_conn. Variables can be set and retrieved through use of
the ad_conn procedure. The following variables are available for public use.
If the ad_conn procedure doesn't recognize a variable being passed to it
for a lookup, it tries to get a value using ns_conn. This guarantees that
-ad_conn subsumes the functionality of ns_conn.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-