[DM] RFC 2396 compatible traversal parameters

[Andreas Jung]

2. Introduction

Haufe uses this features in iDesk to make passing the so called area (information about the active tab) more robust. It allows to use virtual host technology to pass on area such that in normal cases the area is maintained autmotatically. Action is necessary only when the active tab is to be changed.

3. Abstract

RFC2396 defines the overall uri structure. Hierachical uri schemes have a path component consisting of a sequence of path segments. Each path segment consists of a name and optionally a sequence of parameters separated by ;. This proposal describes how Zope's publishing component can be enhanced to support path segment parameters, herein called traversal parameters.

4. Rationale

There are some important use cases that require information to be kept across successive requests. The most prominent ones are maintaining the session id as well as skin and language selection. We recently met more special ones: keeping tab activation and information about the authentication domain (for remote login). The currently available solutions store this information in:

    * the session
    * a cookie
    * the URL

Session and cookie storage have the disadvantages that they do not play well with the browser's history function and that they can seriously confuse caching (mittigated a bit by appropriate 'vary' cache controls, but not solved). Furthermore, cookies might not be available for security reasons.

URL storage does not suffer these disadvantages but currently requires the introduction of artificial path segments for the additional information and difficult traversal magic to prevent the artificial segements from interfering with the traversal process. Traversal parameters can solve this much more naturally than artificial path segments.

Zope currently does not support traversal parameters.

5. Usage Types

Traversal parameters can have two kinds of uses:

    * controlling the traversal process itself
    * providing information for the whole request

Skin selection belongs for example to the first kind, tab activation to the second one; language selection may belong to either of them.

While it seems most natural to attach information for the whole request to the last path segment, it is much more practical to use some path segment further to the front as this information might be used automatically (without explicit URL construction) by relative uri references.

6. Risks

Support for traversal parameters controlling the traversal process itself will inevitably require deeper changes in Zope's traversal implementation. As this implementation is already quite complex and supports many use cases, the new extension might break some of them. I will outline the special risks in the solution part.

There might be clients not implementing RFC 2396. Such clients might support parameters only at the path end and view everything after the first ; as part of the parameters. Such clients might resolve relative uri references incorrectly in the presence of traversal parameters.

7. Proposed Solution

The solution modifies Zope's ZPublisher.BaseRequest.BaseRequest.traverse.

Currently, the path argument is split into a sequence of names, maintained reversed in the TraversalRequestNameStack. The solution splits it into a sequence of pairs, consisting of the name and the sequence of parameters. TraversalRequestNameStack will contain the name only when the parameter sequence is empty but the pair, otherwise. Usually, this will allow traversal magic (modification of TraversalRequestNameStack to change the traversal process) to continue to work as previously unless it hits a pair when it expects a name only. Such (hopefully rare) cases will break.

When the traversal process has located a subobject, it checks whether it provides or is adaptable to the interface ZPublisher.interfaces.IRfc2396TraversalParamerters or defines a __traversal_parameter_process_hook__. If so, it calls the interface's process_traversal_parameters or the hook with request and the parameter list as arguments. The call may change the parameter list which will affect the parameters added to the constructed (URL) path segment. It can, of course, change request variables as well.

The traversal will maintain the parameters for the current step in TraversalRequestStepParameterList to make them available for __bobo_traverse__. An aware __bobo_traverse__ implementation might change this list affecting the parameters seen in further processing.

To support parameters destined to the complete request (rather than individual traversal steps), all found parameters are collected in TraversalRequestCollectedParameterList. Individual steps that want to modify the collected parameters can assign a new list to TraversalRequestStepCollectParameterList. The original value is a reference to TraversalRequestStepParameterList. Thus, if it is changed in place, this other list changes as well.

For an application, it is difficult to work with parameter lists. Therefore, BaseRequest gets the new method dictifyParameters. It takes a parameter list as argument and returns a parameter dictionary. It performs the same conversions and assemblies as ZPublisher.HTTPRequest.HTTPRequest.processInputs. To avoid code duplication, processInputs is refactored.

After traversal, the request gets a lazy key TraversalRequestCollectedParameterDict. It makes the collected traversal parameters available as a dictionary.

[ChrisW (chris-simplistix)]

Just to note that, years ago, the ; stuff in urls was looked at for Zope 3 traversal. It was going to be used to find the view, however, the idea was dropped due to patchy implementation in browsers.

[Colin Watson (cjwatson)]

The zope2 project on Launchpad has been archived at the request of the Zope developers (see https://answers.launchpad.net/launchpad/+question/683589 and https://answers.launchpad.net/launchpad/+question/685285). If this bug is still relevant, please refile it at https://github.com/zopefoundation/zope2.