You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1758 lines
70 KiB
1758 lines
70 KiB
<HTML>
|
|
<HEAD>
|
|
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252">
|
|
<TITLE>PEP - an Extension Mechanism for HTTP</TITLE>
|
|
</HEAD>
|
|
<BODY BGCOLOR="#ffffff" TEXT="#000000" LINK="#0000ff" VLINK="#7f007f">
|
|
<P ALIGN="right">
|
|
<A HREF="http://www.w3.org"><IMG SRC="http://www.w3.org/Icons/WWW/w3c_home"
|
|
WIDTH="72" HEIGHT="48" ALIGN="Left" ALT="W3C" BORDER="0"></A><STRONG>WD-http-pep-971121</STRONG>
|
|
<P>
|
|
<BR>
|
|
<H1 ALIGN="CENTER">
|
|
PEP - an Extension Mechanism for HTTP
|
|
</H1>
|
|
<H2 ALIGN="CENTER">
|
|
W3C Working Draft 21 November 1997
|
|
</H2>
|
|
<DL>
|
|
<DT>
|
|
Authors
|
|
<DD>
|
|
<A HREF="#frystyk">Henrik Frystyk Nielsen</A>,
|
|
<A HREF="#connolly">Dan Connolly</A>,
|
|
<A HREF="#khare">Rohit Khare</A>,
|
|
<A HREF="#prudhommeaux ">Eric Prud'hommeaux</A>
|
|
<DT>
|
|
This version:
|
|
<DD>
|
|
<A HREF="http://www.w3.org/TR/WD-http-pep-970526">http://www.w3.org/TR/WD-http-pep-971121</A>
|
|
<DD>
|
|
$Id: WD-http-pep-971121.html,v 1.2 1998/04/07 21:31:46 fillault Exp $
|
|
<DT>
|
|
Latest Released Version:
|
|
<DD>
|
|
<A HREF="http://www.w3.org/TR/WD-http-pep">http://www.w3.org/TR/WD-http-pep</A>
|
|
<DT>
|
|
Previous Versions:
|
|
<DD>
|
|
<A HREF="http://www.w3.org/TR/WD-http-pep-970428">http://www.w3.org/TR/WD-http-pep-970714</A>
|
|
<BR>
|
|
<A HREF="http://www.w3.org/TR/WD-http-pep-970428">http://www.w3.org/TR/WD-http-pep-970428</A>
|
|
<BR>
|
|
<A HREF="http://www.w3.org/TR/WD-http-pep-970321">http://www.w3.org/TR/WD-http-pep-970321</A>
|
|
<BR>
|
|
<A HREF="http://www.w3.org/TR/WD-http-pep-970131">http://www.w3.org/TR/WD-http-pep-970131</A>
|
|
<BR>
|
|
<A HREF="http://www.w3.org/TR/WD-http-pep-960820">http://www.w3.org/TR/WD-http-pep-960820</A>
|
|
<BR>
|
|
<A HREF="http://www.w3.org/TR/WD-http-pep-960819">http://www.w3.org/TR/WD-http-pep-960819</A>
|
|
<BR>
|
|
<A HREF="http://www.w3.org/TR/WD-http-pep-960222">http://www.w3.org/TR/WD-http-pep-960222</A>
|
|
<BR>
|
|
<A HREF="http://www.w3.org/TR/WD-http-pep-951122">http://www.w3.org/TR/WD-http-pep-951122</A>
|
|
<BR>
|
|
<A HREF="http://www.w3.org/TR/WD-http-pep-960220">http://www.w3.org/TR/WD-http-pep-960220</A>
|
|
</DL>
|
|
<H1>
|
|
Status of this Document
|
|
</H1>
|
|
<P>
|
|
This is a W3C Working Draft for review by W3C members and other interested
|
|
parties. It is a draft document and may be updated, replaced or made obsolete
|
|
by other documents at any time. It is inappropriate to use W3C Working Drafts
|
|
as reference material or to cite them as other than "work in progress." A
|
|
list of current W3C working drafts can be found at "http://www.w3.org/TR".
|
|
This WD has also been submitted as IETF ID
|
|
<draft-ietf-http-pep-05.txt>.
|
|
<P>
|
|
The PEP specification has gone through a thorough design phase and entered
|
|
a steady state where the authors do not intend to modify the document any
|
|
further. At the same time we have developed practical experience with the
|
|
PEP demo code (available from "http://www.w3.org/Protocols/PEP") which
|
|
demonstrates both client, server, and proxy interactions using dynamic loaded
|
|
PEP extensions. However, we believe that it is essential for a specification
|
|
to be tested in real world applications before being deployed at large, which
|
|
is the reason for the status as Experimental.
|
|
<H1>
|
|
Abstract
|
|
</H1>
|
|
<P>
|
|
HTTP is used increasingly in applications that need more facilities than
|
|
the standard version of the protocol provides, ranging from distributed
|
|
authoring, collaboration, and printing, to various remote procedure call
|
|
mechanisms. The Protocol Extension Protocol (PEP) is an extension mechanism
|
|
designed to address the tension between private agreement and public
|
|
specification and to accommodate extension of applications such as HTTP clients,
|
|
servers, and proxies. The PEP mechanism is designed to associate each extension
|
|
with a URI[2], and use a few new RFC 822[1] derived header fields to carry
|
|
the extension identifier and related information between the parties involved
|
|
in an extended transaction.
|
|
<P>
|
|
This document defines PEP and describes the interactions between PEP and
|
|
HTTP/1.1[7]. PEP is intended to be compatible with HTTP/1.0[5] inasmuch as
|
|
HTTP/1.1 is compatible with HTTP/1.0 (see [7], section 19.7). It is proposed
|
|
that the PEP extension mechanism be included in future versions of HTTP.
|
|
<P>
|
|
The PEP extension mechanism may be applicable to other information exchange
|
|
not mentioned in this document. It is recommended that readers get acquainted
|
|
with section 1.4 for a suggested reading of this specification and a list
|
|
of sections specific for HTTP based applications.
|
|
<H1>
|
|
Table of Contents
|
|
</H1>
|
|
<OL>
|
|
<LI>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743936">Introduction</A>
|
|
<DL compact>
|
|
<DT>
|
|
1.1
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743937">Requirements</A>
|
|
<DT>
|
|
1.2
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743938">Purpose</A>
|
|
<DT>
|
|
1.3
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743939">Operational Overview</A>
|
|
<DT>
|
|
1.4
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743940">Guide to this Specification</A>
|
|
</DL>
|
|
<LI>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743941">The PEP Extension Space in
|
|
HTTP</A>
|
|
<LI>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743942">Notational Conventions</A>
|
|
<DL compact>
|
|
<DT>
|
|
3.1
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743943">Bag Syntax</A>
|
|
</DL>
|
|
<LI>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743944">Extension Declarations</A>
|
|
<DL compact>
|
|
<DT>
|
|
4.1
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743945">Mapping Header Fields</A>
|
|
<DT>
|
|
4.2
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743946">The Strength of a
|
|
Declaration</A>
|
|
<DT>
|
|
4.3
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743947">End-to-End Extension
|
|
Declarations</A>
|
|
<DT>
|
|
4.4
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743948">Hop-by-Hop Extension
|
|
Declarations</A>
|
|
</DL>
|
|
<LI>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743949">Extension Policy
|
|
Information</A>
|
|
<DL compact>
|
|
<DT>
|
|
5.1
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743950">The Realm of a Policy</A>
|
|
<DT>
|
|
5.2
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743951">Policy Expirations</A>
|
|
<DT>
|
|
5.3
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743952">Extra Parameters</A>
|
|
<DT>
|
|
5.4
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743953">End-to-End Policies</A>
|
|
<DT>
|
|
5.5
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743954">Hop-by-Hop Policies</A>
|
|
</DL>
|
|
<LI>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743955">Publishing an Extension</A>
|
|
<LI>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743956">Binding HTTP Requests</A>
|
|
<DL compact>
|
|
<DT>
|
|
7.1
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743957">Extending Existing HTTP
|
|
Methods</A>
|
|
<DT>
|
|
7.2
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743958">Adding New HTTP Methods</A>
|
|
</DL>
|
|
<LI>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743959">HTTP Status Codes</A>
|
|
<DL compact>
|
|
<DT>
|
|
8.1
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743960">420 Policy Not Fulfilled</A>
|
|
<DT>
|
|
8.2
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743961">421 Bad Mapping</A>
|
|
</DL>
|
|
<LI>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743962">HTTP Proxy Servers</A>
|
|
<DL compact>
|
|
<DT>
|
|
9.1
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743963">Proxy Servers as End-to-End
|
|
Recipients</A>
|
|
<DL compact>
|
|
<DT>
|
|
9.1.1
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743964">Proxy Servers Acting on Behalf
|
|
of User Agents</A>
|
|
<DT>
|
|
9.1.2
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743965">Proxy Servers Acting on Behalf
|
|
of Origin Servers</A>
|
|
</DL>
|
|
<DT>
|
|
9.2
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743966">Proxy Servers and Repeated
|
|
Hop-by-Hop Extensions</A>
|
|
</DL>
|
|
<LI>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743967">Practical Considerations
|
|
for HTTP</A>
|
|
<DL compact>
|
|
<DT>
|
|
10.1
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743968">Interaction with Existing
|
|
HTTP/1.1 Methods</A>
|
|
<DT>
|
|
10.2
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743969">Interaction with Existing
|
|
HTTP/1.1 Headers</A>
|
|
<DT>
|
|
10.3
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743970">Server Initiated Extension
|
|
Declarations</A>
|
|
</DL>
|
|
<LI>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743971">Security Considerations</A>
|
|
<LI>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743972">Normative References</A>
|
|
<LI>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743973">Bibliography: Informative
|
|
References</A>
|
|
<LI>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743974">Acknowledgements</A>
|
|
<LI>
|
|
<A HREF="WD-http-pep-971121.html#Authors">Authors Addresses</A>
|
|
<LI>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743976">Summary of PEP Interactions</A>
|
|
<LI>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743977">Examples</A>
|
|
<DL compact>
|
|
<DT>
|
|
17.1
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743978">Client Queries Server for
|
|
DAV</A>
|
|
<DT>
|
|
17.2
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743979">Client Informs Server about
|
|
ZipFlate Compression Extension</A>
|
|
<DT>
|
|
17.3
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743980">Server Uses Content-Digest
|
|
Extension</A>
|
|
<DT>
|
|
17.4
|
|
<DD>
|
|
<A HREF="WD-http-pep-971121.html#_Toc404743981">Server Requires Client to
|
|
use Payment Extension</A>
|
|
</DL>
|
|
</OL>
|
|
<H1>
|
|
1. <A NAME="_Toc404743936">Introduction</A>
|
|
</H1>
|
|
<H2>
|
|
1.1 <A NAME="_Toc404743937">Requirements</A>
|
|
</H2>
|
|
<P>
|
|
HTTP is a generic request-response protocol, designed to accommodate a variety
|
|
of applications, from network information exchange and searching to file
|
|
transfer and repository access to query and forms processing.
|
|
<P>
|
|
Most HTTP transactions are initiated by a user agent issuing a request to
|
|
be applied to a resource on some origin server, with intermediaries between
|
|
them in some cases. The origin server replies with a response indicating
|
|
the result of the transaction.
|
|
<P>
|
|
Semantically, however, an HTTP transaction is between the principal accessing
|
|
a resource (end user) and the principal responsible for the publication of
|
|
a given resource (publisher). The publisher is responsible for the service
|
|
provided at any particular URI, for example, the mapping between the URI
|
|
and any representation of the resource to which it refers. The end user accesses
|
|
information provided by a publisher. Exactly who takes the role as end user
|
|
or publisher is beyond the scope of this document.
|
|
<P>
|
|
HTTP, as is the case for most transaction based information exchange protocols,
|
|
is used increasingly in applications that need more facilities than the standard
|
|
version of the protocol provides, from distributed authoring, collaboration
|
|
and printing, to various remote procedure call mechanisms.
|
|
<P>
|
|
Many extended applications do not require agreement across the whole Internet
|
|
about the extended facilities; rather, it suffices:
|
|
<UL>
|
|
<LI>
|
|
That conforming peers supporting a particular protocol extension or feature
|
|
can employ it dynamically with no prior agreement;
|
|
<LI>
|
|
That it is possible for one party having a capability for a new protocol
|
|
to require that the other party either understand and abide by the new protocol
|
|
or abort the operation;
|
|
<LI>
|
|
That negotiation of matching capabilities is possible.
|
|
</UL>
|
|
<P>
|
|
The need for extensibility creates a tension between dynamically extensible
|
|
applications and public, static specifications.
|
|
<H2>
|
|
1.2 <A NAME="_Toc404743938">Purpose</A>
|
|
</H2>
|
|
<P>
|
|
The Protocol Extension Protocol (PEP) is an extension mechanism designed
|
|
to accommodate dynamic extension of HTTP applications by software components;
|
|
and to address the tension between private agreement and public specification.
|
|
The kind of extensions capable of being introduced by PEP range from:
|
|
<UL>
|
|
<LI>
|
|
extending a single protocol message;
|
|
<LI>
|
|
introducing new encodings;
|
|
<LI>
|
|
initiating HTTP-derived protocols for new applications; to...
|
|
<LI>
|
|
switching to protocols which, once initiated, run independent of the original
|
|
protocol stack.
|
|
</UL>
|
|
<P>
|
|
This document defines the protocol extension mechanism referred to as "PEP".
|
|
The PEP design is the result of analyzing a variety of extensions and extension
|
|
mechanisms in HTTP and HTTP-like protocols, and the motivation behind them.
|
|
<P>
|
|
The specification also describes the interactions between PEP and HTTP/1.1[7]
|
|
including scoping rules and cache semantics. PEP is intended to be compatible
|
|
with HTTP/1.0[5] inasmuch as HTTP/1.1 is compatible with HTTP/1.0 (see section
|
|
1.4 and 10) and it is proposed that the PEP extension mechanism be included
|
|
in future versions of HTTP.
|
|
<H2>
|
|
1.3<A NAME="_Toc404743939"> Operational Overview</A>
|
|
</H2>
|
|
<P>
|
|
PEP is intended to be used as follows:
|
|
<UL>
|
|
<LI>
|
|
Some party designs and specifies an extension; the party assigns the extension
|
|
an identifier, which is a URI, and makes one or more representations of the
|
|
extension available at that address (see section 6).
|
|
<LI>
|
|
A party using a PEP compliant agent with an implementation of the extension
|
|
wishes to use it; the agent declares the use of the extension by referencing
|
|
its URI in a PEP extension declaration (see section 4).
|
|
<LI>
|
|
Information about extensions can be passed between agents including information
|
|
of where they can be used and under what conditions (see section 5).
|
|
</UL>
|
|
<P>
|
|
If an extension becomes ubiquitous, it may be incorporated into a new version
|
|
of the base protocol, hence transitioning from dynamic extension to static
|
|
specification. In this case, applications can refer to the new version of
|
|
the base protocol instead of the PEP extension (see section 6).
|
|
<P>
|
|
PEP extension declarations are characterized by the following properties:
|
|
<UL>
|
|
<LI>
|
|
They link features introduced by the extension to the URI identifying the
|
|
extension, potentially allowing a recipient to interpret the message correctly
|
|
with no prior agreement.
|
|
<LI>
|
|
They contain a <I>strength</I> and a <I>scope</I> allowing the sender to
|
|
define the appropriate action to be taken by the recipient even if it does
|
|
not understand the semantics of the extension.
|
|
<LI>
|
|
Any agent can generate declarations independent of other agents
|
|
</UL>
|
|
<P>
|
|
The advantage of including the extension identifier is that, at the cost
|
|
of some extra bytes to spell out the URI, the use of a central registry of
|
|
extension names is avoided. PEP can also be used to extend applications to
|
|
support centrally registered extensions, assuming a URI is published as part
|
|
of the registration (see section 6).
|
|
<P>
|
|
The PEP mechanism is designed to accommodate but does not require dynamic
|
|
extension of clients, servers, and proxies by software components as follows:
|
|
<UL>
|
|
<LI>
|
|
Clients and servers could be implemented with software component interfaces
|
|
that allow dynamic installation of extension facilities.
|
|
<LI>
|
|
An implementation compatible with a software component interface supported
|
|
by the agent could be made available at the URI identifying the extension.
|
|
<LI>
|
|
An agent receiving a message referring to an extension not known by the agent
|
|
could dereference the extension's identifier and dynamically load support
|
|
for the extended facility.
|
|
</UL>
|
|
<P>
|
|
The representation and implementation of dynamic extensible software component
|
|
interfaces is outside the scope of this specification.
|
|
<H2>
|
|
1.4 <A NAME="_Toc404743940">Guide to this Specification</A>
|
|
</H2>
|
|
<P>
|
|
This specification is organized as follows: Section 2 describes how PEP fits
|
|
into HTTP. This is not required reading but may further the understanding
|
|
of the specification. Section 3 is an overview of the notational conventions
|
|
used throughout the specification.
|
|
<P>
|
|
Section 4, 5, and 6 is the core part of the specification describing the
|
|
generic PEP extension mechanism. Section 7, 8, 9, and 10 describe the
|
|
interactions between PEP and HTTP/1.1[7].
|
|
<P>
|
|
The generic PEP extension mechanism may be applicable to other information
|
|
exchange protocols. Such mappings, however, are outside the scope of this
|
|
specification.
|
|
<H1>
|
|
2. <A NAME="_Toc404743941">The PEP Extension Space in HTTP</A>
|
|
</H1>
|
|
<P>
|
|
PEP is designed to support dynamic extensibility of HTTP methods, headers,
|
|
and status codes. Before describing in detail how PEP does this, it is
|
|
constructive to have a look at how methods, headers, and status codes behave
|
|
in HTTP:
|
|
<DL>
|
|
<DT>
|
|
Methods
|
|
<DD>
|
|
The method token in an HTTP request indicates the method to be performed
|
|
on the resource identified by the <TT>Request-URI</TT>. Methods need a priori
|
|
agreement of semantics and can not be extended dynamically. If an HTTP server
|
|
does not know a method, it must report an error message (see [7] section
|
|
5.1.1). A limitation of the method space is that a request can only contain
|
|
a single method. Hence, it is not possible to support multiple, simultaneous
|
|
extensions unless having a multiplicity of methods.
|
|
<DT>
|
|
Status Codes
|
|
<DD>
|
|
The status code element is a 3-digit integer result code of the attempt to
|
|
understand and satisfy the request. Status codes are like method tokens in
|
|
that there can only be a single status code in a response. However, status
|
|
codes are somewhat easier to extend, as unknown status codes must be treated
|
|
as the x00 cod-e of that class (see [7] section 6.1.1). For example, a new
|
|
status code, 223 (My New Code) would default to 200 (OK).
|
|
<DT>
|
|
Headers
|
|
<DD>
|
|
Header fields can be used to pass information about any of the parties involved
|
|
in the transaction, the transaction itself, or the resource identified by
|
|
the Request-URI. The advantage of headers is that the header space is relatively
|
|
open compared to that of methods and status codes. New headers can be introduced
|
|
and must be ignored if the recipient does not recognize the header without
|
|
affecting the outcome of the transaction (see [7] section 7.1).
|
|
</DL>
|
|
<P>
|
|
In order to achieve the desired flexibility, PEP is designed to use the header
|
|
space for describing extensions and not directly HTTP methods or status codes.
|
|
Instead, PEP introduces a placeholder in the method space and status code
|
|
space respectively guaranteeing that all interactions with existing HTTP
|
|
applications perform according to the PEP specification. The two placeholders
|
|
are:
|
|
<UL>
|
|
<LI>
|
|
a special <TT>PEP</TT> method and a <TT>PEP-</TT> method prefix which indicates
|
|
that a request contains one or more PEP extensions that must be adhered to
|
|
or the transaction aborted (see section 7);
|
|
<LI>
|
|
a special status code 420 (Policy Not Fulfilled) that indicates that the
|
|
policy for accessing the resource was not met and that further information
|
|
can be found in the response for diagnosing the problem (see section 8.1).
|
|
</UL>
|
|
<P>
|
|
These two placeholders allow for multiple PEP extensions to be deployed
|
|
simultaneously without overloading the method space or the status code space.
|
|
<H1>
|
|
3. <A NAME="_Toc404743942">Notational Conventions</A>
|
|
</H1>
|
|
<P>
|
|
This specification uses the same notational conventions and basic parsing
|
|
constructs as RFC 2068[7]. In particular the BNF constructs "<TT>token</TT>",
|
|
"<TT>quoted-string</TT>", "<TT>field-name</TT>", "<TT>URI</TT>", and
|
|
"<TT>delta-seconds</TT>" in this document are to be interpreted as described
|
|
in RFC 2068[7].
|
|
<P>
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
|
|
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to
|
|
be interpreted as described in RFC 2119[9].
|
|
<P>
|
|
PEP does not rely on particular features defined in URLs [3] that cannot
|
|
potentially be expressed using URNs (see section 6). Therefore, the more
|
|
generic term URI[2] is used throughout the specification.
|
|
<H2>
|
|
3.1 <A NAME="_Toc404743943">Bag Syntax</A>
|
|
</H2>
|
|
<P>
|
|
The bag element is a recursive structure that uses braces ("{" and "}") to
|
|
delimit attribute-value pairs that may consist of tokens, quoted-strings,
|
|
URIs and recursively defined bags. The BNF for the bag syntax is as follows:
|
|
<PRE> bag = "{" bagname *bagitem "}"
|
|
bagname = token
|
|
bagitem = bag
|
|
| token
|
|
| quoted-string
|
|
</PRE>
|
|
<P>
|
|
The bag semantics are defined by its context and the bag name. The value
|
|
of a quoted string may be a URI in some cases. Unless explicitly defined
|
|
otherwise, all tokens within a bag are case-insensitive. Comments as defined
|
|
by RFC 822[1] indicated by surrounding the comment text with parentheses
|
|
MUST NOT be used within a bag construct.
|
|
<H1>
|
|
4. <A NAME="_Toc404743944">Extension Declarations</A>
|
|
</H1>
|
|
<P>
|
|
Extension declaration bags are used to indicate the PEP extensions that have
|
|
been applied to a message. The grammar for an extension declaration is as
|
|
follows:
|
|
<PRE> ext-decl = "{" req-ext-attr *opt-ext-attr "}"
|
|
req-ext-attr = map
|
|
|
|
opt-ext-attr = strength
|
|
| attribute-ext
|
|
map = "{" "map" <"> URI <"> #(header-prefix) "}"
|
|
strength = "{" "strength" ( "must" | "may" ) "}"
|
|
|
|
attribute-ext = bag
|
|
header-prefix = 1*DIGIT "-"
|
|
</PRE>
|
|
<P>
|
|
The <TT>map</TT> attribute bag contains the URI identifying the extension
|
|
and a list of any header field names introduced by the extension (see section
|
|
4.1 and 6). If the extension identifier is relative, it is interpreted relative
|
|
to the base URI of the message as defined by RFC 1808[4].
|
|
<P>
|
|
The <TT>strength</TT> attribute bag indicates whether the recipient MUST
|
|
or MAY obey the semantics given by the extension or report an error (see
|
|
section 4.2).
|
|
<P>
|
|
An extension declaration bag (<TT>ext-decl</TT>) can be extended through
|
|
the use of one or more <TT>attribute-ext</TT> bags. Unrecognized
|
|
<TT>attribute-ext</TT> bags SHOULD be ignored and MUST NOT be removed by
|
|
proxies when forwarding the extension declaration (see section 9).
|
|
<P>
|
|
Extension declarations can either be hop-by-hop or end-to-end (see [7], section
|
|
13.5.1) depending on the scope of the declaration (see section 4.3 and 4.4).
|
|
End-to-end declarations MUST be transmitted to the ultimate recipient of
|
|
the extension declaration. Hop-by-hop declarations are meaningful only for
|
|
a single transport-level connection.
|
|
<H2>
|
|
4.1 <A NAME="_Toc404743945">Mapping Header Fields</A>
|
|
</H2>
|
|
<P>
|
|
The <TT>header-prefix</TT> in a <TT>map</TT> attribute bag can be used to
|
|
indicate that all header fields in the message matching the
|
|
<TT>header-prefix</TT> value using string prefix-matching are introduced
|
|
by this extension declaration instance. This allows an extension instance
|
|
to dynamically reserve a part of the header space in the message for introducing
|
|
new header fields without risking header name conflicts with other extension
|
|
instances.
|
|
<P>
|
|
Examples of <TT>header-prefix</TT> values are
|
|
<PRE> 1-, 435-
|
|
546-
|
|
2343543645653-
|
|
</PRE>
|
|
<P>
|
|
Agents SHOULD NOT overload well-known or widely deployed header fields with
|
|
new semantics unless the new semantics are a superset of the existing semantics
|
|
so that the header fields still can be interpreted according to the old
|
|
semantics.
|
|
<P>
|
|
Agents SHOULD NOT reuse already mapped header fields in the same message.
|
|
If a header field is mapped by multiple extension declarations in the same
|
|
message, the recipient SHOULD report an error (see section 8.2).
|
|
<P>
|
|
Proxies adding extension declarations to a message MUST make sure that any
|
|
header fields introduced do not conflict with already mapped header fields
|
|
in that protocol message (see section 8.2).
|
|
<H2>
|
|
4.2 <A NAME="_Toc404743946">The Strength of a Declaration</A>
|
|
</H2>
|
|
<P>
|
|
The <TT>strength</TT> attribute bag can be used to specify the actions to
|
|
be taken by the ultimate recipient of the extension declaration. The
|
|
<TT>strength</TT> value can indicate that
|
|
<OL>
|
|
<LI>
|
|
the recipient MUST obey the extension declaration or report an error; or
|
|
<LI>
|
|
the recipient MAY obey the extension declaration or ignore it altogether.
|
|
</OL>
|
|
<P>
|
|
If the strength is "<TT>must</TT>", the ultimate recipient MUST consult and
|
|
adhere to the rules given by the extension when processing the message or
|
|
report an error (see section 7 and 8.1).
|
|
<P>
|
|
If the strength is "<TT>may</TT>" the ultimate recipient of the extension
|
|
MAY consult and adhere to the rules given by the extension when processing
|
|
the message, or ignore the extension declaration completely. An agent may
|
|
not be able to distinguish whether the ultimate recipient does not understand
|
|
an extension referred to by an extension declaration of strength
|
|
"<TT>may</TT>" or simply ignores the extension declaration.
|
|
<P>
|
|
If no strength attribute is present, the default strength is "<TT>may</TT>".
|
|
<P>
|
|
Not accepting or ignoring an extension declaration is different from not
|
|
accepting a mapping of header <TT>field-name</TT>s introduced by the
|
|
<TT>map</TT> attribute bag. If the ultimate recipient cannot accept a mapping,
|
|
for example if a <TT>field-name</TT> is already mapped by another extension
|
|
declaration in that protocol message, it SHOULD report an error (see section
|
|
8.2).
|
|
<H2>
|
|
4.3 <A NAME="_Toc404743947">End-to-End Extension Declarations</A>
|
|
</H2>
|
|
<P>
|
|
End-to-end declarations MUST be transmitted to the ultimate recipient of
|
|
the declaration. The <TT>PEP</TT> header field is an end-to-end header field
|
|
and is defined as follows:
|
|
<PRE> pep = "PEP" ":" 1#ext-decl
|
|
</PRE>
|
|
<P>
|
|
For example
|
|
<PRE> GET / HTTP/1.1
|
|
Host: some.host
|
|
PEP: {{map "http://www.w3.org/PEP/DAV"}}
|
|
</PRE>
|
|
<P>
|
|
If multiple end-to-end extensions are declared in the same message, the
|
|
declarations MUST be listed in the order in which they were applied to the
|
|
message.
|
|
<P>
|
|
Proxies MAY under certain conditions act as the ultimate recipient of
|
|
declarations on behalf of user agents and origin servers (see section 9.1).
|
|
<H2>
|
|
4.4 <A NAME="_Toc404743948">Hop-by-Hop Extension Declarations</A>
|
|
</H2>
|
|
<P>
|
|
Hop-by-hop extension declarations are meaningful only for a single
|
|
transport-level connection. The <TT>C-PEP</TT> header field is a hop-by-hop
|
|
header field and MUST NOT be communicated by proxies over further connections.
|
|
The <TT>C-PEP</TT> header has the following grammar:
|
|
<PRE> c-pep = "C-PEP" ":" 1#ext-decl
|
|
</PRE>
|
|
<P>
|
|
For example
|
|
<PRE> GET / HTTP/1.1
|
|
Host: some.host
|
|
C-PEP: {{map "http://www.w3.org/PEP/ProxyAuth" 43-}}
|
|
43-Credentials: "fsdgfag"
|
|
Connection: C-PEP, Credentials
|
|
</PRE>
|
|
<P>
|
|
In HTTP, the <TT>C-PEP</TT> header field MUST be protected by a
|
|
<TT>Connection</TT> header by including <TT>C-PEP</TT> as a
|
|
<TT>Connection</TT> header directive. The directive MUST be handled according
|
|
to the HTTP/1.1 specification of the <TT>Connection</TT> header (see section
|
|
10.2 and [7], section 14.10).
|
|
<P>
|
|
An agent MUST NOT send the <TT>C-PEP</TT> header field to an HTTP/1.0 proxy
|
|
as it does not obey the HTTP/1.1 rules for parsing the <TT>Connection</TT>
|
|
header field (see [7], section 19.7.1).
|
|
<P>
|
|
If multiple hop-by-hop extensions are declared in the same message, the extension
|
|
declarations MUST be listed in the order in which they were applied. Hop-by-hop
|
|
<TT>C-PEP</TT> declarations MUST be processed before any end-to-end
|
|
<TT>PEP</TT> declarations.
|
|
<H1>
|
|
5. <A NAME="_Toc404743949">Extension Policy Information</A>
|
|
</H1>
|
|
<P>
|
|
Extension Policy bags are used to indicate the extensions that may be applied
|
|
to a message. Extension policies differ from extension declarations in that
|
|
the latter is information about which extensions <I>have been</I> applied
|
|
to a message. An extension policy is defined as follows:
|
|
<PRE> policy-decl = "{" req-pol-attr *opt-pol-attr "}"
|
|
req-pol-attr = id
|
|
|
|
opt-pol-attr = for
|
|
| max-age
|
|
| parameters
|
|
| strength
|
|
| attribute-ext
|
|
</PRE>
|
|
<PRE> id = "{" "id" <"> URI <"> "}"
|
|
for = "{" "for" #URI-wildcard "}"
|
|
max-age = "{" "max-age" delta-seconds "}"
|
|
|
|
parameters = "{" "params" *bagitem "}"
|
|
URI-wildcard = <"> URI <"> [ wildcard ]
|
|
wildcard = "*"
|
|
</PRE>
|
|
<P>
|
|
The <TT>id</TT> attribute specifies the URI identifying the extension (see
|
|
section 6). If the extension identifier is relative, it is interpreted relative
|
|
to the base URI of the message as defined by RFC 1808[4].
|
|
<P>
|
|
The <TT>for</TT> attribute bag specifies which resources, the policy is intended
|
|
for (see section 5.1) and the <TT>max-age</TT> attribute bag when the information
|
|
should be considered stale (see section 5.2). The <TT>params</TT> attribute
|
|
bag can be used to pass additional information about the extension policy
|
|
(see section 5.3).
|
|
<P>
|
|
The <TT>strength</TT> attribute indicates whether the policy is a requirement
|
|
or optional for the resource(s) for which it applies (see section 4.2).
|
|
<P>
|
|
An extension policy bag (<TT>policy-decl</TT>) can be extended through the
|
|
use of one or more <TT>attribute-ext</TT> bags. Unrecognized
|
|
<TT>attribute-ext</TT> bags SHOULD be ignored and MUST NOT be removed by
|
|
proxies when forwarding the extension policy (see section 9).
|
|
<P>
|
|
Extension policies can either be hop-by-hop or end-to-end policies (see [7],
|
|
section 13.5.1) depending on the scope (see section 5.4 and 5.5). End-to-end
|
|
policies MUST be transmitted to the ultimate recipient of the extension policy.
|
|
Hop-by-hop policies are meaningful only for a single transport-level connection.
|
|
<P>
|
|
<EM>Note: It is expected that extension policies will be integrated with
|
|
other metadata initiatives like the RDF initiative [11], for example.</EM>
|
|
<H2>
|
|
5.1 <A NAME="_Toc404743950">The Realm of a Policy</A>
|
|
</H2>
|
|
<P>
|
|
The <TT>for</TT> attribute bag can be used to specify the resource(s) identified
|
|
by URI(s) to which the policy applies. This allows extension policies to
|
|
be deployed to third party sites and to be distributed by other means than
|
|
directly between the involved parties. A URI followed by a LWS and a wildcard
|
|
("*") represents the set of URIs that contains the given URI using prefix
|
|
matching. A URI with no wildcard means that URI only.
|
|
<P>
|
|
Examples of <TT>URI-wildcards</TT> are
|
|
<PRE> {for "/" *}
|
|
{for "http://www.w3.org/pub/" *}
|
|
{for "secret/Overview.html"}
|
|
</PRE>
|
|
<P>
|
|
An empty <TT>for</TT> attribute bag (no <TT>bagitem</TT>s included) indicates
|
|
that the policy is not applied to any resource. If no <TT>for</TT> attribute
|
|
bag is present, the default value is the <TT>Request-URI</TT>.
|
|
<P>
|
|
A realm can include any number of resources but note that a single wildcard
|
|
"*" is not a valid <TT>URI-wildcard</TT> value.
|
|
<H2>
|
|
5.2 <A NAME="_Toc404743951">Policy Expirations</A>
|
|
</H2>
|
|
<P>
|
|
The <TT>max-age</TT> attribute bag can be used to specify a date/time after
|
|
which the recipient SHOULD consider the policy stale. The <TT>max-age</TT>
|
|
attribute bag value indicates that the information should no longer be used
|
|
if the age is greater than the specified time in seconds (see [7] section
|
|
13.2.3 for how to calculate the age). A <TT>max-age</TT> attribute bag cannot
|
|
be used to force the recipient to discard the policy information; its semantics
|
|
apply only to the caching mechanism of policy information.
|
|
<H2>
|
|
5.3 <A NAME="_Toc404743952">Extra Parameters</A>
|
|
</H2>
|
|
<P>
|
|
The params attribute bag can be used to include additional information about
|
|
the extension or modifiers on the use of the extension. The <TT>params</TT>
|
|
values may or may not be case-sensitive, depending on the semantics of the
|
|
parameter name. The params attribute bag is defined as a generic bag structure,
|
|
which may be nested. No default parameters are defined.
|
|
<P>
|
|
<EM>Note: PEP implementations should pass any parameters to the module or
|
|
modules handling the particular extension as this may have impact the use
|
|
of the extension.</EM>
|
|
<H2>
|
|
5.4 <A NAME="_Toc404743953">End-to-End Policies</A>
|
|
</H2>
|
|
<P>
|
|
End-to-end policies MUST be transmitted to the ultimate recipient of a message.
|
|
The <TT>PEP-Info</TT> header field is an end-to-end header and is defines
|
|
as follows:
|
|
<PRE> pep-info = "PEP-Info" ":" 1#policy-decl
|
|
</PRE>
|
|
<P>
|
|
For example
|
|
<PRE> HTTP/1.1 200 OK
|
|
Content-Type: text/html
|
|
Content-Length: 412
|
|
PEP-Info: {{id "http://some.org/payment-extension"}
|
|
{for "/cgi-bin/buy" *}
|
|
{strength must}}
|
|
|
|
<!doctype html public "-//W3C//DTD HTML 3.2//EN" >
|
|
<html> ...
|
|
</PRE>
|
|
<P>
|
|
Proxies MAY under certain conditions act as the ultimate recipients of extension
|
|
policies on behalf of user agents and origin servers (see section 9.1).
|
|
<H2>
|
|
5.5 <A NAME="_Toc404743954">Hop-by-Hop Policies</A>
|
|
</H2>
|
|
<P>
|
|
Hop-by-hop policies are meaningful only for a single transport-level connection.
|
|
The <TT>C-PEP-Info</TT> header field is a hop-by-hop header field and MUST
|
|
NOT be communicated by proxies over further connections. The
|
|
<TT>C-PEP-Info</TT> header has the following grammar:
|
|
<PRE> c-pep-info = "C-PEP-Info" ":" 1#policy-decl
|
|
</PRE>
|
|
<P>
|
|
For example
|
|
<PRE> HTTP/1.1 420 Policy Not Fulfilled
|
|
C-PEP-Info: {{id "http://some.org/provide-stats"}
|
|
{for "/" *}}
|
|
Connection: C-PEP-Info
|
|
...
|
|
</PRE>
|
|
<P>
|
|
In HTTP, the <TT>C-PEP-Info</TT> header field MUST be protected by a
|
|
<TT>Connection</TT> header by including <TT>C-PEP-Info</TT> as a
|
|
<TT>Connection</TT> header directive. The directive MUST be handled according
|
|
to the HTTP/1.1 specification of the <TT>Connection</TT> header (see section
|
|
10.2 and [7], section 14.10).
|
|
<P>
|
|
An agent MUST NOT send the <TT>C-PEP-Info</TT> header field to an HTTP/1.0
|
|
proxy as it does not obey the HTTP/1.1 rules for parsing the
|
|
<TT>Connection</TT> header field (see [7], section 19.7.1).
|
|
<H1>
|
|
6. <A NAME="_Toc404743955">Publishing an Extension</A>
|
|
</H1>
|
|
<P>
|
|
While the protocol extension definition should be published at the address
|
|
of the extension identifier, this is not a requirement of this specification.
|
|
The only absolute requirement is that distinct names be used for distinct
|
|
semantics. For example, one way to achieve this is to use a <I>mid</I>,
|
|
<I>cid</I>, or <I>uuid</I> URI. The association between the extension identifier
|
|
and the specification might be made by distributing a specification, which
|
|
references the extension identifier.
|
|
<P>
|
|
It is strongly recommended that the integrity and persistence of the extension
|
|
identifier is maintained and kept unquestioned throughout the lifetime of
|
|
the extension. Care should be taken not to distribute conflicting specifications
|
|
that reference the same name. Even when a URI is used to publish extension
|
|
specifications, care must be taken that the specification made available
|
|
at that address does not change significantly over time. One agent may associate
|
|
the identifier with the old semantics, and another might associate it with
|
|
the new semantics.
|
|
<P>
|
|
The extension definition may be made available in different representations
|
|
ranging from
|
|
<UL>
|
|
<LI>
|
|
a human-readable specification defining the extension semantics,
|
|
<LI>
|
|
downloadable code which implements the semantics defined by the extension,
|
|
<LI>
|
|
a formal interface description provided by the extension, to
|
|
<LI>
|
|
a machine-readable specification defining the extension semantics.
|
|
</UL>
|
|
<P>
|
|
For example, a software component that implements the specification may reside
|
|
at the same address as a human-readable specification (distinguished by content
|
|
negotiation). The human-readable representation serves to document the extension
|
|
and encourage deployment, while the software component allows clients and
|
|
servers to be dynamically extended.
|
|
<H1>
|
|
7. <A NAME="_Toc404743956">Binding HTTP Requests</A>
|
|
</H1>
|
|
<P>
|
|
An HTTP request is called a "binding" request if it includes at least one
|
|
PEP extension declaration of strength "<TT>must</TT>". An HTTP server MUST
|
|
NOT return a 2xx <TT>status-code</TT> without obeying all extension
|
|
declaration(s) of strength "<TT>must</TT>" in a binding request. This section
|
|
describes how the binding request mechanism in PEP interacts with existing
|
|
HTTP applications.
|
|
<P>
|
|
In [7], section 7.1, it is stated that "Unrecognized header fields SHOULD
|
|
be ignored by the recipient and MUST be forwarded by proxies." Hence, using
|
|
a <TT>PEP</TT> or a <TT>C-PEP</TT> extension declaration is not sufficient
|
|
to evoke the correct behavior from existing HTTP agents in a binding request.
|
|
However, in [7], section 5.1.1, Method, it is said that "Servers SHOULD return
|
|
501 (Not Implemented) if the method is unrecognized or not implemented by
|
|
the server." A similar statement is made in [5], section 9.5. It is therefore
|
|
safe to assume that using the method name will produce the correct result
|
|
from existing HTTP servers and proxies.
|
|
<P>
|
|
PEP uses the HTTP request method name to extend existing HTTP/1.1 methods
|
|
and to introduce new methods (see section 1.3). In both cases, a binding
|
|
HTTP request invalidates cached entries as described in [7], section 13.10.
|
|
Responses to binding requests are not cachable.
|
|
<H2>
|
|
7.1 <A NAME="_Toc404743957">Extending Existing HTTP Methods</A>
|
|
</H2>
|
|
<P>
|
|
The method name of all HTTP/1.1 requests containing a PEP extension declaration
|
|
of strength "<TT>must</TT>" that semantically extends that method MUST be
|
|
prefixed by "<TT>PEP-</TT>" (see section 10.1). For example, a client might
|
|
express the binding rights-management constraints in an HTTP PUT request
|
|
as follows:
|
|
<PRE> PEP-PUT /a-resource HTTP/1.1
|
|
PEP: {{map "http://www.w3.org/PEP/rights-management" 8-}
|
|
{strength must}}
|
|
8-copyright: http://www.w3.org/COPYRIGHT.html
|
|
8-contributions: http://www.w3.org/PATCHES.html
|
|
Host: www.w3.org
|
|
Content-Length: 1203
|
|
Content-Type: text/html
|
|
|
|
<!doctype html ...
|
|
</PRE>
|
|
<P>
|
|
The ultimate recipient of a binding HTTP request with the "<TT>PEP-</TT>"
|
|
prefix on the method name MUST process the request by performing the following
|
|
actions in the order they occur:
|
|
<OL>
|
|
<LI>
|
|
Identify all extension declarations (both hop-by-hop and end-to-end) of strength
|
|
"<TT>must</TT>"; the server MAY ignore declarations of strength
|
|
"<TT>may</TT>" without affecting the result of the transaction;
|
|
<LI>
|
|
Evaluate and process the extensions identified in 1) in the order they were
|
|
declared (see section 4.3 and 4.4) or if the extension declarations do not
|
|
match the policy for accessing the resource then respond with a 420 (Policy
|
|
Not Fulfilled) <TT>status-code</TT> (see section 8.1);
|
|
<LI>
|
|
Strip the "<TT>PEP-</TT>" prefix from the method name and process the reminder
|
|
of the request according to the semantics of the existing HTTP/1.1 method
|
|
name as defined in [7].
|
|
</OL>
|
|
<P>
|
|
The "<TT>PEP-</TT>" prefix is reserved by PEP and MUST NOT be used by other
|
|
HTTP extensions.
|
|
<H2>
|
|
7.2 <A NAME="_Toc404743958">Adding New HTTP Methods</A>
|
|
</H2>
|
|
<P>
|
|
The PEP method can be used for all PEP extension declarations of strength
|
|
"<TT>must</TT>" that do not naturally extend existing HTTP/1.1 methods. Such
|
|
methods can be address space manipulation extensions like MOVE and COPY,
|
|
for example:
|
|
<PRE> PEP /source.html HTTP/1.1
|
|
PEP: {{map "http"//www.w3.org/DAV/MOVE" 4-}
|
|
{strength must}}
|
|
4-Destination: destination.html
|
|
Host: some.host
|
|
</PRE>
|
|
<P>
|
|
The <TT>PEP</TT> method indicates that the semantics of this request are
|
|
defined by one or more PEP extension declarations of strength "<TT>must</TT>"
|
|
included in the request. The PEP method does not have any HTTP message semantics
|
|
besides being a placeholder for PEP extension declarations and hence all
|
|
other semantics MUST be defined by the declaration(s) included in the request.
|
|
<P>
|
|
The ultimate recipient of a <TT>PEP</TT> request MUST process the request
|
|
by doing the following:
|
|
<OL>
|
|
<LI>
|
|
Identify all extension declarations (both hop-by-hop and end-to-end) of strength
|
|
"must"; the server MAY ignore declarations of strength "<TT>may</TT>" without
|
|
affecting the result of the transaction;
|
|
<LI>
|
|
Evaluate and process the extensions identified in 1) in the order they were
|
|
declared (see section 4.3 and 4.4) or if the extension declarations do not
|
|
match the policy for accessing the resource then respond with a 420 (Policy
|
|
Not Fulfilled) <TT>status-code</TT> (see section 8.1);
|
|
</OL>
|
|
<P>
|
|
A successful response SHOULD be 200 (OK) if the response includes an entity,
|
|
202 (Accepted) if the action has not yet been enacted, or 204 (No Content)
|
|
if the response is OK but does not include an entity. If no extension
|
|
declarations have strength "<TT>must</TT>", the response SHOULD be 400 (Bad
|
|
Request).
|
|
<P>
|
|
The <TT>PEP</TT> method is reserved by PEP and MUST NOT be used by other
|
|
HTTP extensions.
|
|
<H1>
|
|
8. <A NAME="_Toc404743959">HTTP Status Codes</A>
|
|
</H1>
|
|
<P>
|
|
PEP introduces two new status codes in addition to the ones already defined
|
|
by HTTP/1.1[7]. Each <TT>Status-Code</TT> is described below, including a
|
|
description the metainformation required in the response.
|
|
<H2>
|
|
8.1 <A NAME="_Toc404743960">420 Policy Not Fulfilled</A>
|
|
</H2>
|
|
<P>
|
|
The policy for accessing the resource has not been met in the request. The
|
|
response MUST include a <TT>PEP-Info</TT> or a <TT>C-PEP-Info</TT> header
|
|
field specifying the extensions required by the publishing party for accessing
|
|
the resource. The server MAY use the <TT>for</TT> attribute bag to indicate
|
|
whether the policy applies to other resources.
|
|
<P>
|
|
The client MAY repeat the request using the appropriate extension(s). If
|
|
the initial request already included the extensions requested in the 420
|
|
response, then the response indicates that access has been refused for those
|
|
extension declarations.
|
|
<P>
|
|
If the 420 response contains the same set of extension policies as the prior
|
|
response, then the client MAY present any entity included in the response
|
|
to the user, since that entity may include relevant diagnostic information.
|
|
<P>
|
|
Implementers may note the similarity to the way authentication challenges
|
|
are issued with the 401 (Unauthorized) <TT>status-code</TT> (see [7], section
|
|
10.4.2)
|
|
<H2>
|
|
8.2 <A NAME="_Toc404743961">421 Bad Mapping</A>
|
|
</H2>
|
|
<P>
|
|
The mappings indicated by one or more <TT>map</TT> attribute bags in the
|
|
request were not unique and mapped the same header field more than once.
|
|
The client MAY repeat the request using a new set of mappings if it believes
|
|
that it can find a unique set of header fields for which the transaction
|
|
will succeed.
|
|
<H1>
|
|
9. <A NAME="_Toc404743962">HTTP Proxy Servers</A>
|
|
</H1>
|
|
<P>
|
|
This section describes the role of caching and non-caching proxies and how
|
|
they interact with PEP extensions. Normally, the ultimate recipient of an
|
|
end-to-end extension declaration or an end-to-end extension policy is an
|
|
origin server or a user agent.
|
|
<P>
|
|
In this case, a proxy MUST forward all components of the extension, including
|
|
declarations, policies, headers, and any methods and status codes defined
|
|
by this specification.
|
|
<P>
|
|
In other cases, however, intermediate caching and non-caching proxies MAY
|
|
be authorized to act on behalf of origin servers and/or user agents. How
|
|
such an agreement is reached between a party representing the proxy and the
|
|
party on which behalf it can act, is outside the scope of PEP, but for example,
|
|
the parties may be within the same trust domain.
|
|
<H2>
|
|
9.1 <A NAME="_Toc404743963">Proxy Servers as End-to-End Recipients</A>
|
|
</H2>
|
|
<H3>
|
|
9.1.1 <A NAME="_Toc404743964">Proxy Servers Acting on Behalf of User Agents</A>
|
|
</H3>
|
|
<P>
|
|
In case a proxy is authorized to act as the ultimate recipient on behalf
|
|
of its proxy clients on end-to-end extensions, it MUST obey the following
|
|
rules:
|
|
<UL>
|
|
<LI>
|
|
The proxy SHOULD remove the extension declaration(s) and any header fields
|
|
that are part of these declaration(s) on which it can act authoritatively
|
|
before forwarding the response to the proxy client;
|
|
<LI>
|
|
it SHOULD issue extension policies for the extensions on which it can act
|
|
authoritatively as if it was a user agent;
|
|
<LI>
|
|
if an extension declaration added by an HTTP proxy is of strength
|
|
"<TT>must</TT>", the proxy MUST either prepend the "<TT>PEP-</TT>" method
|
|
name prefix or use the <TT>PEP</TT> method instead of the method name used
|
|
in the proxy client request, before forwarding the response to the origin
|
|
server (see section 7.1).
|
|
</UL>
|
|
<P>
|
|
An example of a proxy acting on behalf of one or more user agents is an
|
|
elementary school wishing to enforce a certain policy for accessing information
|
|
on the Internet. The local school proxy can act authoritatively as a retrieval
|
|
filter on behalf of the pupils instead of having distributed filtering enabled
|
|
on each of the user agents using the client.
|
|
<H3>
|
|
9.1.2 <A NAME="_Toc404743965">Proxy Servers Acting on Behalf of Origin
|
|
Servers</A>
|
|
</H3>
|
|
<P>
|
|
In case a proxy is authorized to act as the ultimate recipient on behalf
|
|
of an origin server on end-to-end extensions, it MUST obey the following
|
|
rules:
|
|
<P>
|
|
The proxy SHOULD remove the extension declaration(s) and any header fields
|
|
that are part of these declaration(s) on which it can act authoritatively
|
|
before forwarding the request to the origin server;
|
|
<UL>
|
|
<LI>
|
|
it SHOULD issue extension policies for the extensions on which it can act
|
|
authoritatively as if it was an origin server;
|
|
<LI>
|
|
if an extension declaration added by an HTTP proxy is of strength
|
|
"<TT>must</TT>" and there are no other extension declarations of strength
|
|
"<TT>must</TT>" in the request, the proxy MUST remove any "<TT>PEP-</TT>"
|
|
method name prefix before forwarding the request to the origin server (see
|
|
section 7.1);
|
|
<LI>
|
|
if a request uses the <TT>PEP</TT> method, the proxy MUST NOT forward the
|
|
request to the origin server unless the communication between the proxy and
|
|
the origin server can be completed using an existing HTTP/1.1 method.
|
|
</UL>
|
|
<P>
|
|
An example of a proxy acting on behalf of an origin server is a corporation
|
|
having a subscription on an on-line journal. All access to the origin server
|
|
goes through the corporate firewall that runs a caching proxy server. The
|
|
organization reports to the publisher of the journal on a monthly basis at
|
|
which point the subscription is re-evaluated. In the day-to-day access, the
|
|
proxy has the authority to act authoritatively on behalf of the origin server
|
|
registering usage of the journal.
|
|
<H2>
|
|
9.2 <A NAME="_Toc404743966">Proxy Servers and Repeated Hop-by-Hop
|
|
Extensions</A>
|
|
</H2>
|
|
<P>
|
|
If a PEP extension is to be used on parts of a message path, including user
|
|
agents, origin servers, and proxies, not covered by end-to-end or hop-by-hop
|
|
extension declarations, it can be defined as a repeated hop-by-hop extension.
|
|
This can for example be the case for a proxy extension applied to a subset
|
|
of proxies in a message path.
|
|
<P>
|
|
It is for the designer of the extension to decide whether it can repeat itself
|
|
on a hop-by-hop basis. In other words, any scope more complex than a hop-by-hop
|
|
or an end-to-end scope is a property of the extension and is transparent
|
|
to PEP.
|
|
<H1>
|
|
10. <A NAME="_Toc404743967">Practical Considerations for HTTP</A>
|
|
</H1>
|
|
<P>
|
|
This section describes some practical considerations intended for PEP extended
|
|
HTTP applications. The issues described may not apply to other information
|
|
retrieval protocols.
|
|
<H2>
|
|
10.1 <A NAME="_Toc404743968">Interaction with Existing HTTP/1.1 Methods</A>
|
|
</H2>
|
|
<P>
|
|
Extension designers should consider whether an extension is to work with
|
|
existing HTTP/1.1 methods using the "<TT>PEP-</TT>" method token prefix or
|
|
with the <TT>PEP</TT> method (see section 7.1 and 7.2). This specification
|
|
does not provide an absolute rule for when to use the <TT>PEP</TT> method
|
|
compared to the "<TT>PEP-</TT>" method token prefix except that the
|
|
"<TT>PEP-</TT>" method token prefix is required in situations where intermediate
|
|
proxies may act authoritatively on behalf of origin servers or user agents
|
|
(see section 9.1.1 and 9.1.2). In case the extension can be used with existing
|
|
methods then it should be considered whether the extension can be used with
|
|
any of the existing HTTP/1.1 methods or only a subset of them.
|
|
<P>
|
|
Some HTTP/1.1 methods follow the convention of being "safe" to the requester
|
|
meaning that they should never have the significance of taking an action
|
|
other than retrieval (see [7], section 9.1). This is for example the case
|
|
of the <TT>GET</TT> and the <TT>HEAD</TT> method. As PEP extension declarations
|
|
of strength "<TT>must</TT>" explicitly modify or replace the method name,
|
|
existing HTTP applications will never be able to mistake a PEP enabled message
|
|
for any of the existing HTTP messages indicated as being safe.
|
|
<P>
|
|
Some extensions may have the property of "idempotence" in that (aside from
|
|
error or expiration issues) the side effects of N > 0 identical extended
|
|
requests is the same as for a single extended request. If this is <I>not</I>
|
|
the case for a PEP extension then it should consider whether it wants to
|
|
1) disable itself on repeated requests, and/or 2) inform a user about the
|
|
behavior of repeating identical requests with this extension.
|
|
<H2>
|
|
10.2 <A NAME="_Toc404743969">Interaction with Existing HTTP/1.1 Headers</A>
|
|
</H2>
|
|
<P>
|
|
Designers of extensions to be used within the HTTP messaging model should
|
|
consider the interaction with existing HTTP/1.1 headers. Especially, it should
|
|
be noted that PEP is designed to be compatible with HTTP/1.0[5] inasmuch
|
|
as HTTP/1.1 is compatible with HTTP/1.0 (see [7], section 19.7).
|
|
<P>
|
|
The <TT>Connection</TT> header as described in [7], section 14.10, allows
|
|
the sender to specify options that are desired for that particular transport
|
|
connection only. All PEP hop-by-hop extension declarations and policies along
|
|
with any header fields introduced by extension declarations MUST be included
|
|
as <TT>Connection</TT> header directives. PEP applications MUST NOT send
|
|
any hop-by-hop extension declarations or policies to HTTP/1.0 proxies as
|
|
they do not obey the rules of HTTP/1.1 for parsing the <TT>Connection</TT>
|
|
header field (see also [7], section 19.7.1).
|
|
<P>
|
|
The <TT>Upgrade</TT> header, [7], section 14.41, allows the client to specify
|
|
what additional communication protocols it supports and would like to use
|
|
if the server finds it appropriate to switch protocols. PEP provides the
|
|
same functionality but without the need for a central registry of protocol
|
|
names. PEP compliant agents MAY use the 101 (Switching Protocols) status
|
|
code to switch to HTTP-based protocols and protocols, which once initiated,
|
|
run completely independently of HTTP.
|
|
<P>
|
|
The content coding values in the <TT>Content-Encoding</TT> header as described
|
|
in [7], section 14.12, indicate an encoding transformation that has been
|
|
applied to an entity. PEP provides the same functionality but without the
|
|
need for a central registry of content codings. As both content codings and
|
|
PEP extension declarations are ordered, using both may lead to ambiguous
|
|
situations. Simultaneous use of both mechanisms is therefore strongly
|
|
discouraged.
|
|
<P>
|
|
An origin server can explicitly prevent intermediaries from applying a
|
|
<TT>Content-Encoding</TT> to a resource by using the <TT>no-transform
|
|
Cache-Control</TT> directive (see [7], section 14.9.4).
|
|
<H2>
|
|
10.3 <A NAME="_Toc404743970">Server Initiated Extension Declarations</A>
|
|
</H2>
|
|
<P>
|
|
PEP extension declarations can be generated by servers as well as clients.
|
|
If a PEP compliant server sends a response with an extension declaration
|
|
referring to an extension that modifies the message in such a way that the
|
|
message can not be decoded without using the extension, and the corresponding
|
|
request was either
|
|
<OL>
|
|
<LI>
|
|
received from a client whose version is lower than HTTP/1.1, or
|
|
<LI>
|
|
received with a <TT>Via</TT> header field indicating that it was forwarded
|
|
by a proxy whose version is lower than HTTP/1.1,
|
|
</OL>
|
|
<P>
|
|
and the response does not already include an <TT>Expires</TT> header, then
|
|
the sender SHOULD include an <TT>Expires</TT> header field whose
|
|
<TT>field-value</TT> is identical to the <TT>field-value</TT> of its
|
|
<TT>Date</TT> header field(see [7], section 14.12). If all agents in the
|
|
message path are HTTP/1.1, then the sender SHOULD use the
|
|
<TT>Cache-Control</TT> header field instead of the <TT>Expires</TT> header
|
|
field to mark the entity uncachable.
|
|
<H1>
|
|
11. <A NAME="_Toc404743971">Security Considerations</A>
|
|
</H1>
|
|
<UL>
|
|
<LI>
|
|
The <TT>for</TT> parameter allows one party to give information about the
|
|
extensions used by another party's resources. The parties may provide resources
|
|
on different servers, or at different addresses on the same server. While
|
|
distinguishing between the parties responsible for different resources at
|
|
the same server may be infeasible, clients SHOULD ignore information given
|
|
by one server about another unless they have reason to trust it, or reason
|
|
to believe that trusting it will have no significant negative consequences.
|
|
<LI>
|
|
Dynamic installation of extension facilities as described in the introduction
|
|
involves software written by one party (the provider of the implementation)
|
|
to be executed under the authority of another (the party operating the host
|
|
software). This opens the host party to a variety of "Trojan horse" attacks
|
|
by the provider, or a malicious third party that forges implementations under
|
|
a provider's name. See, for example RFC2046[6], section 4.5.2 for a discussion
|
|
of these risks.
|
|
</UL>
|
|
<H1>
|
|
12. <A NAME="_Toc404743972">Normative References</A>
|
|
</H1>
|
|
<DL compact>
|
|
<DT>
|
|
[1]
|
|
<DD>
|
|
D. H. Crocker. <I>"Standard for the Format of ARPA Internet Text Messages"</I>,
|
|
STD 11, <A NAME="RFC822">RFC 822</A>, UDEL, August 1982
|
|
<DT>
|
|
[2]
|
|
<DD>
|
|
T. Berners-Lee, <I>"Universal Resource Identifiers in WWW. A Unifying Syntax
|
|
for the Expression of Names and Addresses of Objects on the Network as used
|
|
in the World-Wide Web"</I>, <A NAME="RFC1630">RFC 1630</A>, CERN, June 1994.
|
|
<DT>
|
|
[3]
|
|
<DD>
|
|
T. Berners-Lee, L. Masinter, M. McCahill. <I>"Uniform Resource Locators
|
|
(URL)"</I> <A NAME="RFC1738">RFC 1738</A>, CERN, Xerox PARC, University of
|
|
Minnesota, December 1994.
|
|
<DT>
|
|
[4]
|
|
<DD>
|
|
R. Fielding, <I>"Relative Uniform Resource Locators"</I>,<A NAME="RFC1808">
|
|
RFC 1808</A>, UC Irvine, June 1995.
|
|
<DT>
|
|
[5]
|
|
<DD>
|
|
T. Berners-Lee, R. Fielding, H. Frystyk, <I>"Hypertext Transfer Protocol
|
|
-- HTTP/1.0"</I>, <A NAME="RFC1945">RFC 1945</A>, W3C/MIT, UC Irvine, W3C/MIT,
|
|
May 1996.
|
|
<DT>
|
|
[6]
|
|
<DD>
|
|
N. Freed, N. Borenstein, <I>"Multipurpose Internet Mail Extensions (MIME)
|
|
Part Two: Media Types"</I>, <A NAME="RFC2046">RFC 2046</A>, Innosoft, First
|
|
Virtual, November 1996.
|
|
<DT>
|
|
[7]
|
|
<DD>
|
|
R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, T. Berners-Lee, <I>"Hypertext
|
|
Transfer Protocol -- HTTP/1.1"</I>, <A NAME="RFC2068">RFC 2068</A>, U.C.
|
|
Irvine, DEC W3C/MIT, DEC, W3C/MIT, W3C/MIT, January 1997
|
|
<DT>
|
|
[8]
|
|
<DD>
|
|
D. Kristol, L. Montulli, <I>"HTTP State Management Mechanism"</I>,
|
|
<A NAME="RFC2109">RFC 2109</A>, Bell Laboratories Lucent Technologies, Netscape
|
|
Communications, February 1997
|
|
<DT>
|
|
[9]
|
|
<DD>
|
|
S. Bradner, <I>"Key words for use in RFCs to Indicate Requirement Levels"</I>,
|
|
<A NAME="RFC2119">RFC 2119</A>, Harvard University, March 1997
|
|
<DT>
|
|
[10]
|
|
<DD>
|
|
J. C. Mogul, R. Fielding, J. Gettys, H. Frystyk, <I>"Use and interpretation
|
|
of HTTP version numbers"</I>, Internet Draft <A NAME="RFC2145">RFC 2145</A>,
|
|
DEC, U.C. Irvine, DEC W3C/MIT, W3C/MIT, HTTP Working Group, May, 1997.
|
|
<DT>
|
|
[11]
|
|
<DD>
|
|
O. Lassila, R. Swick, <I>"</I><A NAME="PICSNG">Resource Description Framework
|
|
(RDF) - Model and Syntax</A>", W3C/Nokia, W3C, W3C Working draft, October
|
|
1997. This is work in progress
|
|
<DT>
|
|
[12]
|
|
<DD>
|
|
H. Schulzrinne, A. Rao, R. Lanphier, <I>"</I><A NAME="RTSP">Real Time Streaming
|
|
Protocol (RTSP)</A>", Internet Draft draft-ietf-mmusic-rtsp-05, Columbia
|
|
U./Netscape/Progressive Networks, March 1997. This is work in progress
|
|
<DT>
|
|
[13]
|
|
<DD>
|
|
T. Berners-Lee, R. Fielding, L. Masinter, <I>"<A NAME="URL">Uniform Resource
|
|
Locators (URL)</A>"</I>, Internet Draft draft-fielding-url-syntax-09, W3C/MIT,
|
|
U.C. Irvine, Xerox Corporation, May 1997. This is work in progress
|
|
</DL>
|
|
<H1>
|
|
13. <A NAME="_Toc404743973">Bibliography: Informative References</A>
|
|
</H1>
|
|
<DL compact>
|
|
<DT>
|
|
[14]
|
|
<DD>
|
|
D. Eastlake, <I>"Universal Payment Preamble"</I>, Internet Draft
|
|
draft-eastlake-universal-payment-03, CyberCash, March 1996. This is work
|
|
in progress.
|
|
<DT>
|
|
[15]
|
|
<DD>
|
|
D. M. Kristol, <I>"</I><A NAME="Kristol">A Proposed Extension Mechanism for
|
|
HTTP</A>", Internet Draft draft-kristokl-http-extensions-00, January 1995.
|
|
Document expired.
|
|
<DT>
|
|
[16]
|
|
<DD>
|
|
JEPI, <I>"Selecting Payment Mechanisms Over HTTP"</I>, Internet Draft
|
|
draft-khare-jepi-uppflow-00, W3C, August 1996. Document expired.
|
|
<DT>
|
|
[17]
|
|
<DD>
|
|
J. Miller et al, <I>"PICS Label Syntax and Communication Protocols (Version
|
|
1.1)"</I>, W3C Recommendation REC-PICS-labels, W3C, 31 October 1996
|
|
<DT>
|
|
[18]
|
|
<DD>
|
|
Y. Goland et al, <I>"</I><A NAME="DAV">Extensions for Distributed Authoring
|
|
and Versioning</A>", Internet Draft, draft-jensen-webdav-ext-01, 26 March
|
|
1997. This is work in progress.
|
|
<DT>
|
|
[19]
|
|
<DD>
|
|
N. Borenstein, <I>"A User Agent Configuration Mechanism For Multimedia Mail
|
|
Format Information"</I>, RFC 1524 pp. 12, Bellcore, September 1993.
|
|
<DT>
|
|
[20]
|
|
<DD>
|
|
J. Klensin, N. Freed, M. Rose, E. Stefferud, and D. Crocker. <I>"SMTP Service
|
|
Extensions"</I>, RFC 1869, MCI, Innosoft, Dover Beach Consulting, Network
|
|
Management Associates, Brandenburg Consulting, November 1995.
|
|
<DT>
|
|
[21]
|
|
<DD>
|
|
D. Robinson, <I>"The WWW Common Gateway Interface Version 1.1"</I>, Internet
|
|
Draft draft-robinson-www-interface-01, February 1996. Document expired.
|
|
<DT>
|
|
[22]
|
|
<DD>
|
|
A. Baird-Smith, <I>"Jigsaw: An object oriented server"</I>, W3C Note, June
|
|
1996
|
|
<DT>
|
|
[23]
|
|
<DD>
|
|
H. Frystyk, <I>"</I><A NAME="_Ref392578504">Libwww Architecture</A>", December
|
|
1996
|
|
<DT>
|
|
[24]
|
|
<DD>
|
|
R. Thau, <I>"Design considerations for the Apache Server API"</I>, Fifth
|
|
International World Wide Web Conference, May 6-10, 1996, Paris, France
|
|
<DT>
|
|
[25]
|
|
<DD>
|
|
Netscape Corporation, <I>"The Netscape Server API"</I>
|
|
<DT>
|
|
[26]
|
|
<DD>
|
|
Microsoft Corporation, <I>"Internet Server API Documentation"</I>
|
|
<DT>
|
|
[27]
|
|
<DD>
|
|
Open Market, Inc, <I>"FastCGI - Restoring All CGI's Good Properties -- and
|
|
Then Some"</I>
|
|
<DT>
|
|
[28]
|
|
<DD>
|
|
Spyglass, <I>"Spyglass MicroServer Application Development Interface"</I>
|
|
<DT>
|
|
[29]
|
|
<DD>
|
|
J. Franks, <I>"WN - a Server for the HTTP"</I>
|
|
<DT>
|
|
[30]
|
|
<DD>
|
|
Roxen, <I>"Introduction to Roxen Challenger"</I>
|
|
</DL>
|
|
<H1>
|
|
14. <A NAME="_Toc404743974">Acknowledgements</A>
|
|
</H1>
|
|
<P>
|
|
The PEP protocol is the product of a substantial amount of investigation
|
|
and collaboration. Dave Kristol did some of the first writing on HTTP extension
|
|
mechanisms[15]. Jim Miller and Dave Raggett sketched out an initial design,
|
|
which Rohit Khare wrote up in a number of drafts. Tim Berners-Lee, Anselm
|
|
Baird-Smith, Paul Leach and Daniel Dardailler deserve special recognition
|
|
for their efforts in commenting in the design phase of the protocol. Also
|
|
thanks to Henning Schulzrinne, Anup Rao and Robert Lanphier for pointing
|
|
out the generalities of PEP and providing support for integration with RTSP[12].
|
|
<P>
|
|
This specification is a direct reflection of some implementation work: a
|
|
client implementation in [23] (see the HTPEP module) and a server implementation
|
|
by Eui-Suk Chung and Anit Chakraborty for the JEPI project.
|
|
<P>
|
|
This document has benefited greatly from the comments of all those participating
|
|
in the HTTP-WG. In addition to those already mentioned, the following individuals
|
|
have contributed to this specification:
|
|
<UL>
|
|
<LI>
|
|
Eui-Suk Chung,
|
|
<LI>
|
|
Don Eastlake,
|
|
<LI>
|
|
Roy Fielding,
|
|
<LI>
|
|
Jim Gettys,
|
|
<LI>
|
|
Yaron Goland,
|
|
<LI>
|
|
Phill Hallam-Baker,
|
|
<LI>
|
|
Paul Hoffman,
|
|
<LI>
|
|
Koen Holtman,
|
|
<LI>
|
|
Ora Lassila,
|
|
<LI>
|
|
Larry Masinter, and
|
|
<LI>
|
|
Jim Whitehead
|
|
</UL>
|
|
<H1>
|
|
15. <A NAME="Authors">Authors Addresses</A>
|
|
</H1>
|
|
<P>
|
|
<A NAME="connolly">Dan Connolly</A><BR>
|
|
Architecture Domain Lead, World Wide Web Consortium <BR>
|
|
MIT Laboratory for Computer Science <BR>
|
|
545 Technology Square <BR>
|
|
Cambridge, MA 02139, U.S.A. <BR>
|
|
Email: connolly@w3.org
|
|
<P>
|
|
<A NAME="khare">Rohit Khare</A><BR>
|
|
Technical Staff, World Wide Web Consortium <BR>
|
|
MIT Laboratory for Computer Science <BR>
|
|
545 Technology Square <BR>
|
|
Cambridge, MA 02139, U.S.A. <BR>
|
|
Email: khare@w3.org
|
|
<P>
|
|
<A NAME="frystyk">Henrik Frystyk Nielsen</A><BR>
|
|
Technical Staff, World Wide Web Consortium <BR>
|
|
MIT Laboratory for Computer Science <BR>
|
|
545 Technology Square <BR>
|
|
Cambridge, MA 02139, U.S.A. <BR>
|
|
Email: frystyk@w3.org
|
|
<P>
|
|
<A NAME="prudhommeaux">Eric Prud'hommeaux </A><BR>
|
|
Contractor, World Wide Web Consortium <BR>
|
|
MIT Laboratory for Computer Science <BR>
|
|
545 Technology Square <BR>
|
|
Cambridge, MA 02139, U.S.A. <BR>
|
|
Email: eric@w3.org
|
|
<H1 align="center">
|
|
Appendices
|
|
</H1>
|
|
<H1>
|
|
16. <A NAME="_Toc404743976">Summary of PEP Interactions</A>
|
|
</H1>
|
|
<P>
|
|
The following tables summarize the outcome of strength and scope rules in
|
|
PEP transactions involving PEP compliant and non-PEP compliant HTTP proxies
|
|
and origin servers. The summary is intended as a guide and index to the text,
|
|
but is necessarily cryptic and incomplete. This summary should never be used
|
|
or referenced separately from the complete PEP specification. The tables
|
|
should be read as follows
|
|
<DL>
|
|
<DT>
|
|
Standard processing
|
|
<DD>
|
|
The action taken by an ultimate recipient not understanding or ignoring the
|
|
extension (see section 4.2)
|
|
<DT>
|
|
Extended processing
|
|
<DD>
|
|
The action taken by an ultimate recipient understanding and obeying the extension
|
|
(see section 4.2)
|
|
<DT>
|
|
Forward extension
|
|
<DD>
|
|
The action taken by an intermediate party which is not an ultimate recipient
|
|
(see section 9)
|
|
<DT>
|
|
Strip extension
|
|
<DD>
|
|
The action taken by an intermediate party which is the ultimate recipient
|
|
(see section 9)
|
|
<DT>
|
|
420 (Policy Not Fulfilled)
|
|
<DD>
|
|
The response from an ultimate recipient not understanding or not wishing
|
|
to obey the extension (see section 8.1)
|
|
<DT>
|
|
501 (Not Implemented)
|
|
<DD>
|
|
The response from an ultimate recipient not understanding the "<TT>PEP</TT>"
|
|
method or "<TT>PEP-</TT>" method token prefix (see section 6)
|
|
</DL>
|
|
<P>
|
|
<B></B>
|
|
<P ALIGN="CENTER">
|
|
Table 1: Origin Server
|
|
<DIV align="center">
|
|
<CENTER>
|
|
<TABLE BORDER CELLSPACING="0" WIDTH="625">
|
|
<TR>
|
|
<TH WIDTH="21%" VALIGN="TOP">Scope</TH>
|
|
<TH WIDTH="39%" VALIGN="TOP" COLSPAN="2">Hop-by-hop</TH>
|
|
<TH WIDTH="39%" VALIGN="TOP" COLSPAN="2">End-to-end</TH>
|
|
</TR>
|
|
<TR>
|
|
<TH WIDTH="21%" VALIGN="TOP">Strength</TH>
|
|
<TH WIDTH="20%" VALIGN="TOP">Optional (may)</TH>
|
|
<TH WIDTH="20%" VALIGN="TOP">Required (must)</TH>
|
|
<TH WIDTH="20%" VALIGN="TOP">Optional (may)</TH>
|
|
<TH WIDTH="20%" VALIGN="TOP">Required (must)</TH>
|
|
</TR>
|
|
<TR>
|
|
<TD WIDTH="21%" VALIGN="TOP">PEP not supported</TD>
|
|
<TD WIDTH="20%" VALIGN="TOP">Standard processing</TD>
|
|
<TD WIDTH="20%" VALIGN="TOP">501 (Not Implemented)</TD>
|
|
<TD WIDTH="20%" VALIGN="TOP">Standard processing</TD>
|
|
<TD WIDTH="20%" VALIGN="TOP">501 (Not Implemented)</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD WIDTH="21%" VALIGN="TOP">Extension not supported</TD>
|
|
<TD WIDTH="20%" VALIGN="TOP">Standard processing</TD>
|
|
<TD WIDTH="20%" VALIGN="TOP">420 (Policy Not Fulfilled)</TD>
|
|
<TD WIDTH="20%" VALIGN="TOP">Standard processing</TD>
|
|
<TD WIDTH="20%" VALIGN="TOP">420 (Policy Not Fulfilled)</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD WIDTH="21%" VALIGN="TOP">Extension supported</TD>
|
|
<TD WIDTH="20%" VALIGN="TOP">Extended processing</TD>
|
|
<TD WIDTH="20%" VALIGN="TOP">Extended processing</TD>
|
|
<TD WIDTH="20%" VALIGN="TOP">Extended processing</TD>
|
|
<TD WIDTH="20%" VALIGN="TOP">Extended processing</TD>
|
|
</TR>
|
|
</TABLE>
|
|
</CENTER>
|
|
</DIV>
|
|
<P>
|
|
<B></B>
|
|
<P ALIGN="CENTER">
|
|
Table 2: Proxy Server
|
|
<DIV align="center">
|
|
<CENTER>
|
|
<TABLE BORDER CELLSPACING="0" WIDTH="626">
|
|
<TR>
|
|
<TH WIDTH="21%" VALIGN="TOP">Scope</TH>
|
|
<TH WIDTH="39%" VALIGN="TOP" COLSPAN="2">Hop-by-hop</TH>
|
|
<TH WIDTH="39%" VALIGN="TOP" COLSPAN="2">End-to-end</TH>
|
|
</TR>
|
|
<TR>
|
|
<TH WIDTH="21%" VALIGN="TOP">Strength</TH>
|
|
<TH WIDTH="20%" VALIGN="TOP">Optional (may)</TH>
|
|
<TH WIDTH="20%" VALIGN="TOP">Required (must)</TH>
|
|
<TH WIDTH="20%" VALIGN="TOP">Optional (may)</TH>
|
|
<TH WIDTH="20%" VALIGN="TOP">Required (must)</TH>
|
|
</TR>
|
|
<TR>
|
|
<TD WIDTH="21%" VALIGN="TOP">PEP not supported</TD>
|
|
<TD WIDTH="20%" VALIGN="TOP">Strip extension</TD>
|
|
<TD WIDTH="20%" VALIGN="TOP">501 (Not Implemented)</TD>
|
|
<TD WIDTH="20%" VALIGN="TOP">Forward extension</TD>
|
|
<TD WIDTH="20%" VALIGN="TOP">501 (Not Implemented)</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD WIDTH="21%" VALIGN="TOP">Extension not supported</TD>
|
|
<TD WIDTH="20%" VALIGN="TOP">Strip extension</TD>
|
|
<TD WIDTH="20%" VALIGN="TOP">420 (Policy Not Fulfilled)</TD>
|
|
<TD WIDTH="20%" VALIGN="TOP">Forward extension</TD>
|
|
<TD WIDTH="20%" VALIGN="TOP">Forward extension</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD WIDTH="21%" VALIGN="TOP">Extension supported</TD>
|
|
<TD WIDTH="20%" VALIGN="TOP">Extended processing and strip</TD>
|
|
<TD WIDTH="20%" VALIGN="TOP">Extended processing and strip</TD>
|
|
<TD WIDTH="20%" VALIGN="TOP">Extended processing and strip</TD>
|
|
<TD WIDTH="20%" VALIGN="TOP">Extended processing and strip</TD>
|
|
</TR>
|
|
</TABLE>
|
|
</CENTER>
|
|
</DIV>
|
|
<P>
|
|
|
|
<H1>
|
|
17. <A NAME="_Toc404743977">Examples</A>
|
|
</H1>
|
|
<P>
|
|
The following examples show various scenarios using PEP in HTTP/1.1 requests
|
|
and responses. Information not essential for illustrating the examples is
|
|
left out (referred to as "…")
|
|
<H2>
|
|
17.1 <A NAME="_Toc404743978">Client Queries Server for DAV</A>
|
|
</H2>
|
|
<P>
|
|
In this example, the purpose of using PEP in the request is to determine
|
|
whether a server understands and supports the Distributed Authoring and
|
|
Versioning (DAV) protocol extension [18]. By making the request binding (see
|
|
section 7), the client forces the server to process the extension declaration
|
|
and obey the extension or report an error.
|
|
<PRE> PEP-GET /some.url HTTP/1.1
|
|
Host: some.host
|
|
PEP: {{map "http://www.w3.org/PEP/DAV"}}
|
|
|
|
HTTP/1.1 200 OK
|
|
PEP-Info: {{id "http://www.w3.org/PEP/DAV"} {for "/Henrik" *}}
|
|
...
|
|
</PRE>
|
|
<P>
|
|
The response shows that the server does understand DAV and that the client
|
|
can use it on all resources matching the prefix "<TT>/Henrik</TT>" on that
|
|
server. The policy is informational and other factors like access control
|
|
may prevent the client from actually using DAV on any of these resources.
|
|
<P>
|
|
PEP does not distinguish between querying about or using an extension –
|
|
the PEP declaration is identical. Whether it in fact is a query may depend
|
|
on the request method name and request modifiers.
|
|
<H2>
|
|
17.2 <A NAME="_Toc404743979">Client Informs Server about ZipFlate Compression
|
|
Extension</A>
|
|
</H2>
|
|
<P>
|
|
This example shows a client informing a server that it is capable of handling
|
|
the zipflate compression extension in a response. By issuing an extension
|
|
policy instead of an extension declaration, the client indicates that the
|
|
extension is not used in the request.
|
|
<PRE> GET /Index HTTP/1.1
|
|
Host: some.host
|
|
PEP-Info: {{id "http://www.w3.org/PEP/Encoding"}}
|
|
|
|
HTTP/1.1 200 OK
|
|
PEP: {{map "http://www.w3.org/PEP/Encoding"}}
|
|
Cache-Control: no-transform
|
|
Vary: *
|
|
...
|
|
</PRE>
|
|
<P>
|
|
The response shows that the server knows the extension and decides to use
|
|
it in the response. It furthermore includes the <TT>no-transform</TT>
|
|
<TT>cache-control</TT> directive in order to avoid that proxies add their
|
|
own <TT>content-coding</TT> to the message (see section 10.2) and a
|
|
<TT>Vary</TT> header field indicating that a cache may not use the response
|
|
to reply to a subsequent request without revalidation.
|
|
<P>
|
|
In this example, the client could have used an extension declaration of strength
|
|
"may" instead of an extension policy to achieve the same effect. The request
|
|
would not have been affected as the compression applies to message bodies
|
|
and not headers. If the request were to include a message body, however,
|
|
the difference would be whether the zipflate extension was applied to that
|
|
body or not.
|
|
<H2>
|
|
17.3 <A NAME="_Toc404743980">Server Uses Content-Digest Extension</A>
|
|
</H2>
|
|
<P>
|
|
This example shows a server applying the Content-Digest extension to a response
|
|
message indicating that the client may ignore it. The client has not indicated
|
|
whether it supports the extension or even if it supports PEP.
|
|
<PRE> GET /Index HTTP/1.1
|
|
Host: some.host
|
|
|
|
HTTP/1.1 200 OK
|
|
PEP: {{map "http://www.w3.org/PEP/Digest" 4-}}
|
|
4-Content-Digest: "a0b1c2d3e4f5g6h7i8j9"
|
|
Cache-Control: max-age=3600
|
|
...
|
|
</PRE>
|
|
<P>
|
|
The response is fully cachable and does not require revalidation when replying
|
|
to subsequent requests.
|
|
<H2>
|
|
17.4 <A NAME="_Toc404743981">Server Requires Client to use Payment
|
|
Extension</A>
|
|
</H2>
|
|
<P>
|
|
The last example shows how a server requires a client to use a micro-payment
|
|
extension in order to access a resource causing an additional roundtrip using
|
|
the 420 (Policy Not Fulfilled) status code (see section 8.1). The first request
|
|
does not contain any PEP constructs leading to the error message. A non-PEP
|
|
compliant client will treat this as a 400 (Bad Request) status code and will
|
|
not be able to fulfill the server's requirement in a second request (see
|
|
[7], section 10.4.1)
|
|
<PRE> GET /Index HTTP/1.1
|
|
Host: some.host
|
|
|
|
420 Policy Not Fulfilled
|
|
PEP-Info: {{id "http://www.w3.org/PEP/MiniPayment"}
|
|
{params {Price 0.02USD}} {strength must}}
|
|
|
|
PEP-GET /Index HTTP/1.1
|
|
Host: some.host
|
|
PEP: {{map "http://www.w3.org/PEP/MiniPayment" 12-}
|
|
{strength must}}
|
|
12-Price: 0.02USD
|
|
|
|
HTTP/1.1 200 OK
|
|
...
|
|
</PRE>
|
|
<P>
|
|
The actual price is passed as an extra parameter in the extension policy.
|
|
The client agrees to the price and issues a new request containing the proper
|
|
extension declaration. If it did not agree with the price, it could have
|
|
tried a lower price and depending on the policy of that resource, the server
|
|
may have responded positively.
|
|
<P>
|
|
<A href="http://www.w3.org/Consortium/Legal/ipr-notice.html#Copyright">
|
|
Copyright</A> © 1998 <A href="http://www.w3.org">W3C</A>
|
|
(<A href="http://www.lcs.mit.edu">MIT</A>,
|
|
<A href="http://www.inria.fr/">INRIA</A>,
|
|
<A href="http://www.keio.ac.jp/">Keio</A> ), All Rights Reserved. W3C
|
|
<A href="http://www.w3.org/Consortium/Legal/ipr-notice.html#Legal Disclaimer">liability,</A>
|
|
<A href="http://www.w3.org/Consortium/Legal/ipr-notice.html#W3C Trademarks">trademark</A>,
|
|
<A href="http://www.w3.org/Consortium/Legal/copyright-documents.html">document
|
|
use </A>and
|
|
<A href="http://www.w3.org/Consortium/Legal/copyright-software.html">software
|
|
licensing </A>rules apply.
|
|
</BODY></HTML>
|