Porcupine wiki | Articles / The Porcupine Request Processing Pipeline

Knowing the steps taken by Porcupine before a servlet is executed, will help you understand one of the most important internal mechanisms. This article describes the server's execution plan from the moment a client request is picked up from the queue until the response is sent back to the web connector and then back to the client.

Every valid HTTP request made to the server should have a valid session ID in the URL. Session state held in cookies and particularly cookie management is not yet supported. The session ID follows immediately after the connector's script name and should be enclosed in brackets. If a new request contains no session ID or the session ID is invalid then the server creates a new session ID, assigns to the newly created session the guest account, as defined in the “porcupine.ini” file, and redirects the browser to the requested path, but this time with a valid session ID injected in the URL.

Once the browser is redirected to the new URL, on the server side, Porcupine checks the portion of the URL that follows after the session ID. This is the actual path of the request. This path should address a Porcupine object or a published directory, otherwise an “ItemNotFound ?” exception is raised.

Porcupine objects can be addressed by using the object's ID or the full path. The latter is slower, since the server retrieves all the objects contained in the path by their display name, but more readable. Some examples of HTTP requests that address Porcupine objects are:

 http://server/porcupine.py/{ab9e44738ce39448c8b245d6706dea9a}/

addresses the server's root container

 http://server/porcupine.py/{ab9e44738ce39448c8b245d6706dea9a}/administrators

addresses the administrators' group

 http://server/porcupine.py/{ab9e44738ce39448c8b245d6706dea9a}/
 Administrative Tools/Users and Groups/Administrators

addresses the administrators' group again

Diagram 1 - The Porcupine request processing pipeline

If the request addresses a Porcupine object then this item is retrieved and is assigned to the “item” attribute of the servlet to be executed. If not then this attribute is None. Next, if the user is not authenticated and guests are not allowed the user is redirected to login page, defined in the “porcupine.ini” configuration file.

Then, the server checks if there is a valid servlet binding – registration defined in the “store.xml” configuration file. These registrations (the “reg” nodes) are checked sequentially from top to bottom until one of them matches the request parameters. Each registration node should define the following attributes:

cc: The content class of the requested object (regular expressions accepted)
method: The HTTP method of the request
param: the “cmd” parameter of the query string
client: the string that identifies the client that has submitted the request (regular expressions accepted)
language: the preferred language of the client (regular expressions accepted)
action: the servlet to be executed of the path to the PSP page
filters: semicolon separated list of post processing filters to apply (if any)

If none of the server registrations matches the request parameters then a “NoViewRegistered ?” exception is raised. If the action parameter's reference is invalid then an “InvalidRegistration ?” exception is raised.

Alternatively, if the request addresses a published directory the server examines if the rest of the path addresses a valid resource based on the “config.xml” file contained inside each published directory. The names and the paths of the published directories are defined in the “pubdir.xml” configuration file. For instance requesting the following URL from a mozilla based browser:

 http://server/porcupine.py/__xul/xul_core.js

will serve the Mozilla compatible QuiX ? core JavaScript ? file. The server indeed has a published directory named “__xul” mapped to the “pubdir/__xul” directory. This is defined to the “pubdir.xml” file. The JavaScript ? file to serve is defined in the “config.xml” file inside the “pubdir/__xul” directory. If you see this file you will notice the node:

 <context path="xul_core.js" method="GET" client="Netscape/7|Mozilla/5.0" lang=".*"
 action="core_moz.js" filters="porcupine.filters.postprocessing.Gzip" />

The attributes of this node are:

path: the path requested inside this published directory
method: the HTTP method of the request
client: the string that identifies the client that has submitted the request (regular expressions accepted)
action: the file to load or execute if it is a servlet
filters: semicolon separated list of post processing filters to apply, if any

Finally, once the server has the response before sending it back to the client the post-processing filters are applied sequentially the same order are given in the “filters” attribute.