REQUEST contains the complete information about the current HTTP request that Zope is processing. The most relevant information is available redundantly, in both the original unprocessed form and in a preprocessed form for easy access.
(source: http://www.dieter.handshake.de/pyprojects/zope/book/chap3.html#special_objects )
REQUEST exposes its data as a mapping object. We speak of the request data as the request items or the request variables.
DTML allows you to easily analyze what a request really contains. The DTML template fragment < dtml-var REQUEST>
inserts the current request's data in a clearly formatted HTML structure. This is very useful, in case your form submissions result in difficult to understand behavior.
Request item categories
You can use REQUEST[key]? to access the value associated with key. However, as an HTTP request is complex and contains names in several categories that might conflict with one another, it is sometimes helpful to know, that REQUEST has a finer grained structure that allows to access the names in the different categories in a controlled way.
Explicitly defined request items
The REQUEST method set allows to explicitly define request items. They are collected in the member other, a mapping object. Such definitions are often used to work around a weakness of document templates: they do not support variables that can change their value in the cause of template rendering. Explicitly defined request items are used as a substitute for such variables.
For efficiency reasons, this mapping is used, too, to provide access to form data and cookies. If a name is looked up in REQUEST, then effectively it is looked up in other, and if not found there, it is checked whether it is a Zope defined name or HTTP header. As cookies and form data should be accessible, too, via REQUEST lookup, they are merged into other during initialization. For this merge, form data has higher priority than cookie values.
Form data
The member form is a mapping with all argument information determined by ZPublisher. Usually, this argument information comes from form submission. This gives this member its name. However, arguments can also come from an explicit query string in an URI reference.
Cookies
The user agent sends all cookies that may be relevant for the request in the HTTP header COOKIE. For ease of use, ZPublisher parses this header into the various cookies and makes them available in the member cookies, another mapping.
The COOKIE header may well contain different cookies with the same name. In this case, cookies will map the name to the first value found for that name. According to the cookie specification, this is the most specific cookie value with the given name available for the request locator.
Zope defined request items
Zope defines the following items to facilitate special tasks:
REQUEST
the request object itself. This is a convenience definition for document templates. They have direct access to the names defined by the request object as a mapping. However, is some cases, they need to access the object itself, e.g. to access its members or methods. They can do this via REQUEST.
RESPONSE
the response object
PUBLISHED
the published object. This is the object determined during traversal which is called to generate the response.
PARENTS
the list of objects visited during traversal without the published object itself, in reverse order. This implies PARENTS[0]? is the object visited before the published one and PARENTS[-1]? is the root object.
URL
the request locator without a query string
URLn?, URLPATHn?
URLn? is the prefix of URL that is obtained by removing the last n path segments. This implies that URL0 has the same value as URL,
URL1 is URL with the last path segment removed and so on.
URLPATHn? is the path component of URLn?.
These variables are often used to construct absolute URLs for objects in the neighborhood.
BASEn?, BASEPATHn?
Each BASEn? is a prefix of URL. BASE1 is the URL of the Zope Web site's root object. For n>=1, each BASEn?+1 is obtained form BASEn? by adding the next path segment. If Zope is used via CGI from another Web server, then BASE1 is the URL of the CGI script and BASE0 is obtained from BASE1 by removing the last path segment; otherwise, BASE0 and BASE1 have identical values.
BASEPATHn? is the path component of BASEn?.
These variables are often used to generate absolute URLs for objects high in the hierarchy or even above Zope (if Zope itself is behind another Web server).
BODY, BODYFILE
the request body as a string or a file object, respectively.
See also: How to fake REQUEST in debugger