Extensions may be started for a variety of reasons:
It is known that the other side demands use of this extension:
Server: client has sent a map requesting use of the extension
Client: client has been advised, either through a PEPInfo from the
server, or from some other source, that the server requests use of the
extension for some set of URLS.
The extension provides resources associated with a URL or set of URLs.
The agent uses the extension for all transactions.
The agent uses the extension for transactions with certain addresses (for
instance. authentication or billing for non-sanctioned addresses).
The extension is invoked when another extension is or is not present
It may seem odd to have the extension look for instance data rather than
having PEPAgent handle it, but the extension must handle it for the following
see if there is an instance for the request or reply going out
if so, generate any mapped headers using instance data
if not either an extension/policy declaration or create an instance use
its data for header generation
see if there is an instance for the request or reply coming in
if so, update its instance data from the mapped headers
if not, create an instance or generate a Policy Declaration with a 420
- It may need to be triggered even if no header was sent
- It may rely on other well-known or mapped headers
- It may need to take some action before the header is parsed
It is logical to allow extensions to remap the URL. On the server,
side, this means changing the name of the resource to retrieve. For
GET /countable/Overview.html may mean
- run the accessCounter extension
- retrieve /Overview.html
This works for multiple extensions if the extensions report back to
the PEP engine that the URL has been remapped. This allows the engine
to check applicable extensions for the remapped URL. This has
different ramifications for the client and server.
The client starts with the URL that the user enteres. Extensions map
this URL to show they've already been called and allow the PEP engine
to patern match on the remaining URL. For instance, if the user
enteres a URL of
the client will match on the PEP extension accessCounter and
call it to map itself onto the local URL, changing it to
http://localhost:8888/escape/Overview.html, and telling
the PEP engine that the URL has been remapped. Because there has been
a change, the PEP engine re-checks applicable extensions, this time,
The server's working URI is actually only the filepath portion (the
part that comes in with the GET). As each extension maps the URI, it
changes the file name that the GET or PUT will act upon. It also
changes the name that the PEP engine checks to see what extensions
need to be called.
Since most extensions are called
This is only a problem
Each extension is assigned a stregth which dictates the actions of the
agents that handle or dispatch that extension. It tell the agents
whether they may handle the request even if they don't have that
extension. Because some extensions would break an HTTP agent that
didn't speak them, any request that has required extensions will also
have a custom method in the request line.
An example of this is the
extension which passes content-lengths which, from the perspective of
a random agent, are wrong. A GET request between a client and server
that both have the escapeBody extension would fail to pass
the correct message body through an intervening proxy. Using a
special request, PEP-GET, and declaring the extension to by
hop-by-hop enables the client to be sure that
all parties speak PEP and have the escapeBody extension.
Extensions that an agent can download on the fly are a geek ideal. The
java security manager makes this sort of thing considerably safer than
it has been in the past. See Security for more
discussion of the pitfalls and solutions.
the interface required to support all the dynamic
is discussed in extensions/Overview.html.
@(#) $Id: ExtensionDesign.html,v 1.3 1997/08/03 00:38:57 eric Exp $