URLs and Paths

The URL at which your application shall appear is arguably the first part of the application's user interface that any user will see. In this context, a user can be any of the following things:

Interpreting Path Information

What the URL is supposed to do is to say where (on the Internet or on an intranet) your application resides and which resource or service is being accessed, and these look like this:

http://www.boddie.org.uk/python/WebStack.html

With WebStack, we also talk about a "path" as being just the part of the URL which refers to the resource or service, ignoring the actual Internet address, and so these look like this:

/python/WebStack.html

When writing a Web application, most of the time you just need to concentrate on the path because the address doesn't usually tell you anything you don't already know. What you need to do is to interpret the path specified in the request in order to work out which resource or service the request is destined for.

WebStack API - Path Methods in Transaction Objects

WebStack provides the following transaction methods for inspecting path information:

get_path
This gets the entire path of a resource including parameter information (as described in "Request Parameters and Uploads").
get_path_without_query
This gets the entire path of a resource but without any parameter information.

Sometimes, a "query string" will be provided as part of a URL; for example:

http://www.boddie.org.uk/application?param1=value1

The question mark character marks the beginning of the query string which contains encoded parameter information; such information and its inspection is discussed in "Request Parameters and Uploads".

Paths To and Within an Application

One thing to be aware of in the code of an application is which part of a path refers to the location of the application in a server environment and which refers to some resource within the application itself. Consider this path:
/folder/application/resource
Let us say that the application was deployed in a Zope server instance inside folder and with the name application. We may then say that the path to the application is this:
/folder/application
Meanwhile, the path within the application is just this:
/resource

WebStack API - Paths To Resources Within Applications

On transaction objects, the following methods exist to inspect paths to resources within applications.

get_path_info
This gets the path of a resource within an application.
get_virtual_path_info
This gets the path of a resource within a part of an application - the application itself decides the scope of the path and can set the "virtual path info" using the set_virtual_path_info method.

Approaches to Path Interpretation

There are various differing approaches to the problem of interpreting paths to resources within Web applications, but these can mostly be divided into three categories:

Approach Examples
Path as filesystem WebDAV interface to a repository
Path as resource or service identifier A Web shop with very simple paths, eg. /products, /checkout, /orders
Path as opaque reference An e-mail reader where the messages already have strange and unreadable message identifiers

Path Info Support in Server Environments

The following table summarises the support for paths within applications amongst the supported server environments or frameworks within WebStack:

Framework Behaviour/Level of Support
BaseHTTPRequestHandler Same as path (correct)
CGI Path beyond resource (correct)
Java Servlet API Path beyond context (correct)
mod_python Path beyond resource (correct)
Twisted Same as path (correct)
Webware <= 0.8.1: Not supported (needs ExtraPathInfo support)
> 0.8.1: Path beyond context (correct)
WSGI Path beyond resource (correct)
Zope Path beyond resource (correct)