WD-http-pep-971121
This is a W3C Working Draft for review by W3C members and other interestedparties. It is a draft document and may be updated, replaced or made obsoleteby other documents at any time. It is inappropriate to use W3C Working Draftsas reference material or to cite them as other than "work in progress." Alist 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>.
The PEP specification has gone through a thorough design phase and entereda steady state where the authors do not intend to modify the document anyfurther. At the same time we have developed practical experience with thePEP demo code (available from "http://www.w3.org/Protocols/PEP") whichdemonstrates both client, server, and proxy interactions using dynamic loadedPEP extensions. However, we believe that it is essential for a specificationto be tested in real world applications before being deployed at large, whichis the reason for the status as Experimental.
HTTP is used increasingly in applications that need more facilities thanthe standard version of the protocol provides, ranging from distributedauthoring, collaboration, and printing, to various remote procedure callmechanisms. The Protocol Extension Protocol (PEP) is an extension mechanismdesigned to address the tension between private agreement and publicspecification and to accommodate extension of applications such as HTTP clients,servers, and proxies. The PEP mechanism is designed to associate each extensionwith a URI[2], and use a few new RFC 822[1] derived header fields to carrythe extension identifier and related information between the parties involvedin an extended transaction.
This document defines PEP and describes the interactions between PEP andHTTP/1.1[7]. PEP is intended to be compatible with HTTP/1.0[5] inasmuch asHTTP/1.1 is compatible with HTTP/1.0 (see [7], section 19.7). It is proposedthat the PEP extension mechanism be included in future versions of HTTP.
The PEP extension mechanism may be applicable to other information exchangenot mentioned in this document. It is recommended that readers get acquaintedwith section 1.4 for a suggested reading of this specification and a listof sections specific for HTTP based applications.
HTTP is a generic request-response protocol, designed to accommodate a varietyof applications, from network information exchange and searching to filetransfer and repository access to query and forms processing.
Most HTTP transactions are initiated by a user agent issuing a request tobe applied to a resource on some origin server, with intermediaries betweenthem in some cases. The origin server replies with a response indicatingthe result of the transaction.
Semantically, however, an HTTP transaction is between the principal accessinga resource (end user) and the principal responsible for the publication ofa given resource (publisher). The publisher is responsible for the serviceprovided at any particular URI, for example, the mapping between the URIand any representation of the resource to which it refers. The end user accessesinformation provided by a publisher. Exactly who takes the role as end useror publisher is beyond the scope of this document.
HTTP, as is the case for most transaction based information exchange protocols,is used increasingly in applications that need more facilities than the standardversion of the protocol provides, from distributed authoring, collaborationand printing, to various remote procedure call mechanisms.
Many extended applications do not require agreement across the whole Internetabout the extended facilities; rather, it suffices:
The need for extensibility creates a tension between dynamically extensibleapplications and public, static specifications.
The Protocol Extension Protocol (PEP) is an extension mechanism designedto 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:
This document defines the protocol extension mechanism referred to as "PEP".The PEP design is the result of analyzing a variety of extensions and extensionmechanisms in HTTP and HTTP-like protocols, and the motivation behind them.
The specification also describes the interactions between PEP and HTTP/1.1[7]including scoping rules and cache semantics. PEP is intended to be compatiblewith HTTP/1.0[5] inasmuch as HTTP/1.1 is compatible with HTTP/1.0 (see section1.4 and 10) and it is proposed that the PEP extension mechanism be includedin future versions of HTTP.
PEP is intended to be used as follows:
If an extension becomes ubiquitous, it may be incorporated into a new versionof the base protocol, hence transitioning from dynamic extension to staticspecification. In this case, applications can refer to the new version ofthe base protocol instead of the PEP extension (see section 6).
PEP extension declarations are characterized by the following properties:
The advantage of including the extension identifier is that, at the costof some extra bytes to spell out the URI, the use of a central registry ofextension names is avoided. PEP can also be used to extend applications tosupport centrally registered extensions, assuming a URI is published as partof the registration (see section 6).
The PEP mechanism is designed to accommodate but does not require dynamicextension of clients, servers, and proxies by software components as follows:
The representation and implementation of dynamic extensible software componentinterfaces is outside the scope of this specification.
This specification is organized as follows: Section 2 describes how PEP fitsinto HTTP. This is not required reading but may further the understandingof the specification. Section 3 is an overview of the notational conventionsused throughout the specification.
Section 4, 5, and 6 is the core part of the specification describing thegeneric PEP extension mechanism. Section 7, 8, 9, and 10 describe theinteractions between PEP and HTTP/1.1[7].
The generic PEP extension mechanism may be applicable to other informationexchange protocols. Such mappings, however, are outside the scope of thisspecification.
PEP is designed to support dynamic extensibility of HTTP methods, headers,and status codes. Before describing in detail how PEP does this, it isconstructive to have a look at how methods, headers, and status codes behavein HTTP:
In order to achieve the desired flexibility, PEP is designed to use the headerspace for describing extensions and not directly HTTP methods or status codes.Instead, PEP introduces a placeholder in the method space and status codespace respectively guaranteeing that all interactions with existing HTTPapplications perform according to the PEP specification. The two placeholdersare:
These two placeholders allow for multiple PEP extensions to be deployedsimultaneously without overloading the method space or the status code space.
This specification uses the same notational conventions and basic parsingconstructs as RFC 2068[7]. In particular the BNF constructs "token","quoted-string", "field-name", "URI", and"delta-seconds" in this document are to be interpreted as describedin RFC 2068[7].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD","SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are tobe interpreted as described in RFC 2119[9].
PEP does not rely on particular features defined in URLs [3] that cannotpotentially be expressed using URNs (see section 6). Therefore, the moregeneric term URI[2] is used throughout the specification.
The bag element is a recursive structure that uses braces ("{" and "}") todelimit attribute-value pairs that may consist of tokens, quoted-strings,URIs and recursively defined bags. The BNF for the bag syntax is as follows:
bag = "{" bagname *bagitem "}" bagname = token bagitem = bag | token | quoted-stringThe bag semantics are defined by its context and the bag name. The valueof a quoted string may be a URI in some cases. Unless explicitly definedotherwise, all tokens within a bag are case-insensitive. Comments as definedby RFC 822[1] indicated by surrounding the comment text with parenthesesMUST NOT be used within a bag construct.
Extension declaration bags are used to indicate the PEP extensions that havebeen applied to a message. The grammar for an extension declaration is asfollows:
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 "-"Themap attribute bag contains the URI identifying the extensionand a list of any header field names introduced by the extension (see section4.1 and 6). If the extension identifier is relative, it is interpreted relativeto the base URI of the message as defined by RFC 1808[4].
Thestrength attribute bag indicates whether the recipient MUSTor MAY obey the semantics given by the extension or report an error (seesection 4.2).
An extension declaration bag (ext-decl) can be extended throughthe use of one or moreattribute-ext bags. Unrecognizedattribute-ext bags SHOULD be ignored and MUST NOT be removed byproxies when forwarding the extension declaration (see section 9).
Extension declarations can either be hop-by-hop or end-to-end (see [7], section13.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 ofthe extension declaration. Hop-by-hop declarations are meaningful only fora single transport-level connection.
Theheader-prefix in amap attribute bag can be used toindicate that all header fields in the message matching theheader-prefix value using string prefix-matching are introducedby this extension declaration instance. This allows an extension instanceto dynamically reserve a part of the header space in the message for introducingnew header fields without risking header name conflicts with other extensioninstances.
Examples ofheader-prefix values are
1-, 435- 546- 2343543645653-
Agents SHOULD NOT overload well-known or widely deployed header fields withnew semantics unless the new semantics are a superset of the existing semanticsso that the header fields still can be interpreted according to the oldsemantics.
Agents SHOULD NOT reuse already mapped header fields in the same message.If a header field is mapped by multiple extension declarations in the samemessage, the recipient SHOULD report an error (see section 8.2).
Proxies adding extension declarations to a message MUST make sure that anyheader fields introduced do not conflict with already mapped header fieldsin that protocol message (see section 8.2).
Thestrength attribute bag can be used to specify the actions tobe taken by the ultimate recipient of the extension declaration. Thestrength value can indicate that
If the strength is "must", the ultimate recipient MUST consult andadhere to the rules given by the extension when processing the message orreport an error (see section 7 and 8.1).
If the strength is "may" the ultimate recipient of the extensionMAY consult and adhere to the rules given by the extension when processingthe message, or ignore the extension declaration completely. An agent maynot be able to distinguish whether the ultimate recipient does not understandan extension referred to by an extension declaration of strength"may" or simply ignores the extension declaration.
If no strength attribute is present, the default strength is "may".
Not accepting or ignoring an extension declaration is different from notaccepting a mapping of headerfield-names introduced by themap attribute bag. If the ultimate recipient cannot accept a mapping,for example if afield-name is already mapped by another extensiondeclaration in that protocol message, it SHOULD report an error (see section8.2).
End-to-end declarations MUST be transmitted to the ultimate recipient ofthe declaration. ThePEP header field is an end-to-end header fieldand is defined as follows:
pep = "PEP" ":" 1#ext-decl
For example
GET / HTTP/1.1 Host: some.host PEP: {{map "http://www.w3.org/PEP/DAV"}}If multiple end-to-end extensions are declared in the same message, thedeclarations MUST be listed in the order in which they were applied to themessage.
Proxies MAY under certain conditions act as the ultimate recipient ofdeclarations on behalf of user agents and origin servers (see section 9.1).
Hop-by-hop extension declarations are meaningful only for a singletransport-level connection. TheC-PEP header field is a hop-by-hopheader field and MUST NOT be communicated by proxies over further connections.TheC-PEP header has the following grammar:
c-pep = "C-PEP" ":" 1#ext-decl
For example
GET / HTTP/1.1 Host: some.host C-PEP: {{map "http://www.w3.org/PEP/ProxyAuth" 43-}} 43-Credentials: "fsdgfag" Connection: C-PEP, CredentialsIn HTTP, theC-PEP header field MUST be protected by aConnection header by includingC-PEP as aConnection header directive. The directive MUST be handled accordingto the HTTP/1.1 specification of theConnection header (see section10.2 and [7], section 14.10).
An agent MUST NOT send theC-PEP header field to an HTTP/1.0 proxyas it does not obey the HTTP/1.1 rules for parsing theConnectionheader field (see [7], section 19.7.1).
If multiple hop-by-hop extensions are declared in the same message, the extensiondeclarations MUST be listed in the order in which they were applied. Hop-by-hopC-PEP declarations MUST be processed before any end-to-endPEP declarations.
Extension Policy bags are used to indicate the extensions that may be appliedto a message. Extension policies differ from extension declarations in thatthe latter is information about which extensionshave been appliedto a message. An extension policy is defined as follows:
policy-decl = "{" req-pol-attr *opt-pol-attr "}" req-pol-attr = id opt-pol-attr = for | max-age | parameters | strength | attribute-ext id = "{" "id" <"> URI <"> "}" for = "{" "for" #URI-wildcard "}" max-age = "{" "max-age" delta-seconds "}" parameters = "{" "params" *bagitem "}" URI-wildcard = <"> URI <"> [ wildcard ] wildcard = "*"Theid attribute specifies the URI identifying the extension (seesection 6). If the extension identifier is relative, it is interpreted relativeto the base URI of the message as defined by RFC 1808[4].
Thefor attribute bag specifies which resources, the policy is intendedfor (see section 5.1) and themax-age attribute bag when the informationshould be considered stale (see section 5.2). Theparams attributebag can be used to pass additional information about the extension policy(see section 5.3).
Thestrength attribute indicates whether the policy is a requirementor optional for the resource(s) for which it applies (see section 4.2).
An extension policy bag (policy-decl) can be extended through theuse of one or moreattribute-ext bags. Unrecognizedattribute-ext bags SHOULD be ignored and MUST NOT be removed byproxies when forwarding the extension policy (see section 9).
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-endpolicies MUST be transmitted to the ultimate recipient of the extension policy.Hop-by-hop policies are meaningful only for a single transport-level connection.
Note: It is expected that extension policies will be integrated withother metadata initiatives like the RDF initiative [11], for example.
Thefor attribute bag can be used to specify the resource(s) identifiedby URI(s) to which the policy applies. This allows extension policies tobe deployed to third party sites and to be distributed by other means thandirectly between the involved parties. A URI followed by a LWS and a wildcard("*") represents the set of URIs that contains the given URI using prefixmatching. A URI with no wildcard means that URI only.
Examples ofURI-wildcards are
{for "/" *} {for "http://www.w3.org/pub/" *} {for "secret/Overview.html"}An emptyfor attribute bag (nobagitems included) indicatesthat the policy is not applied to any resource. If nofor attributebag is present, the default value is theRequest-URI.
A realm can include any number of resources but note that a single wildcard"*" is not a validURI-wildcard value.
Themax-age attribute bag can be used to specify a date/time afterwhich the recipient SHOULD consider the policy stale. Themax-ageattribute bag value indicates that the information should no longer be usedif the age is greater than the specified time in seconds (see [7] section13.2.3 for how to calculate the age). Amax-age attribute bag cannotbe used to force the recipient to discard the policy information; its semanticsapply only to the caching mechanism of policy information.
The params attribute bag can be used to include additional information aboutthe extension or modifiers on the use of the extension. Theparamsvalues may or may not be case-sensitive, depending on the semantics of theparameter name. The params attribute bag is defined as a generic bag structure,which may be nested. No default parameters are defined.
Note: PEP implementations should pass any parameters to the module ormodules handling the particular extension as this may have impact the useof the extension.
End-to-end policies MUST be transmitted to the ultimate recipient of a message.ThePEP-Info header field is an end-to-end header and is definesas follows:
pep-info = "PEP-Info" ":" 1#policy-decl
For example
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> ...Proxies MAY under certain conditions act as the ultimate recipients of extensionpolicies on behalf of user agents and origin servers (see section 9.1).
Hop-by-hop policies are meaningful only for a single transport-level connection.TheC-PEP-Info header field is a hop-by-hop header field and MUSTNOT be communicated by proxies over further connections. TheC-PEP-Info header has the following grammar:
c-pep-info = "C-PEP-Info" ":" 1#policy-decl
For example
HTTP/1.1 420 Policy Not Fulfilled C-PEP-Info: {{id "http://some.org/provide-stats"} {for "/" *}} Connection: C-PEP-Info ...In HTTP, theC-PEP-Info header field MUST be protected by aConnection header by includingC-PEP-Info as aConnection header directive. The directive MUST be handled accordingto the HTTP/1.1 specification of theConnection header (see section10.2 and [7], section 14.10).
An agent MUST NOT send theC-PEP-Info header field to an HTTP/1.0proxy as it does not obey the HTTP/1.1 rules for parsing theConnection header field (see [7], section 19.7.1).
While the protocol extension definition should be published at the addressof the extension identifier, this is not a requirement of this specification.The only absolute requirement is that distinct names be used for distinctsemantics. For example, one way to achieve this is to use amid,cid, oruuid URI. The association between the extension identifierand the specification might be made by distributing a specification, whichreferences the extension identifier.
It is strongly recommended that the integrity and persistence of the extensionidentifier is maintained and kept unquestioned throughout the lifetime ofthe extension. Care should be taken not to distribute conflicting specificationsthat reference the same name. Even when a URI is used to publish extensionspecifications, care must be taken that the specification made availableat that address does not change significantly over time. One agent may associatethe identifier with the old semantics, and another might associate it withthe new semantics.
The extension definition may be made available in different representationsranging from
For example, a software component that implements the specification may resideat the same address as a human-readable specification (distinguished by contentnegotiation). The human-readable representation serves to document the extensionand encourage deployment, while the software component allows clients andservers to be dynamically extended.
An HTTP request is called a "binding" request if it includes at least onePEP extension declaration of strength "must". An HTTP server MUSTNOT return a 2xxstatus-code without obeying all extensiondeclaration(s) of strength "must" in a binding request. This sectiondescribes how the binding request mechanism in PEP interacts with existingHTTP applications.
In [7], section 7.1, it is stated that "Unrecognized header fields SHOULDbe ignored by the recipient and MUST be forwarded by proxies." Hence, usingaPEP or aC-PEP extension declaration is not sufficientto 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 return501 (Not Implemented) if the method is unrecognized or not implemented bythe server." A similar statement is made in [5], section 9.5. It is thereforesafe to assume that using the method name will produce the correct resultfrom existing HTTP servers and proxies.
PEP uses the HTTP request method name to extend existing HTTP/1.1 methodsand to introduce new methods (see section 1.3). In both cases, a bindingHTTP request invalidates cached entries as described in [7], section 13.10.Responses to binding requests are not cachable.
The method name of all HTTP/1.1 requests containing a PEP extension declarationof strength "must" that semantically extends that method MUST beprefixed by "PEP-" (see section 10.1). For example, a client mightexpress the binding rights-management constraints in an HTTP PUT requestas follows:
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 ...The ultimate recipient of a binding HTTP request with the "PEP-"prefix on the method name MUST process the request by performing the followingactions in the order they occur:
The "PEP-" prefix is reserved by PEP and MUST NOT be used by otherHTTP extensions.
The PEP method can be used for all PEP extension declarations of strength"must" that do not naturally extend existing HTTP/1.1 methods. Suchmethods can be address space manipulation extensions like MOVE and COPY,for example:
PEP /source.html HTTP/1.1 PEP: {{map "http"//www.w3.org/DAV/MOVE" 4-} {strength must}} 4-Destination: destination.html Host: some.hostThePEP method indicates that the semantics of this request aredefined by one or more PEP extension declarations of strength "must"included in the request. The PEP method does not have any HTTP message semanticsbesides being a placeholder for PEP extension declarations and hence allother semantics MUST be defined by the declaration(s) included in the request.
The ultimate recipient of aPEP request MUST process the requestby doing the following:
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 extensiondeclarations have strength "must", the response SHOULD be 400 (BadRequest).
ThePEP method is reserved by PEP and MUST NOT be used by otherHTTP extensions.
PEP introduces two new status codes in addition to the ones already definedby HTTP/1.1[7]. EachStatus-Code is described below, including adescription the metainformation required in the response.
The policy for accessing the resource has not been met in the request. Theresponse MUST include aPEP-Info or aC-PEP-Info headerfield specifying the extensions required by the publishing party for accessingthe resource. The server MAY use thefor attribute bag to indicatewhether the policy applies to other resources.
The client MAY repeat the request using the appropriate extension(s). Ifthe initial request already included the extensions requested in the 420response, then the response indicates that access has been refused for thoseextension declarations.
If the 420 response contains the same set of extension policies as the priorresponse, then the client MAY present any entity included in the responseto the user, since that entity may include relevant diagnostic information.
Implementers may note the similarity to the way authentication challengesare issued with the 401 (Unauthorized)status-code (see [7], section10.4.2)
The mappings indicated by one or moremap attribute bags in therequest 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 believesthat it can find a unique set of header fields for which the transactionwill succeed.
This section describes the role of caching and non-caching proxies and howthey interact with PEP extensions. Normally, the ultimate recipient of anend-to-end extension declaration or an end-to-end extension policy is anorigin server or a user agent.
In this case, a proxy MUST forward all components of the extension, includingdeclarations, policies, headers, and any methods and status codes definedby this specification.
In other cases, however, intermediate caching and non-caching proxies MAYbe authorized to act on behalf of origin servers and/or user agents. Howsuch an agreement is reached between a party representing the proxy and theparty on which behalf it can act, is outside the scope of PEP, but for example,the parties may be within the same trust domain.
In case a proxy is authorized to act as the ultimate recipient on behalfof its proxy clients on end-to-end extensions, it MUST obey the followingrules:
An example of a proxy acting on behalf of one or more user agents is anelementary school wishing to enforce a certain policy for accessing informationon the Internet. The local school proxy can act authoritatively as a retrievalfilter on behalf of the pupils instead of having distributed filtering enabledon each of the user agents using the client.
In case a proxy is authorized to act as the ultimate recipient on behalfof an origin server on end-to-end extensions, it MUST obey the followingrules:
The proxy SHOULD remove the extension declaration(s) and any header fieldsthat are part of these declaration(s) on which it can act authoritativelybefore forwarding the request to the origin server;
An example of a proxy acting on behalf of an origin server is a corporationhaving a subscription on an on-line journal. All access to the origin servergoes through the corporate firewall that runs a caching proxy server. Theorganization reports to the publisher of the journal on a monthly basis atwhich point the subscription is re-evaluated. In the day-to-day access, theproxy has the authority to act authoritatively on behalf of the origin serverregistering usage of the journal.
If a PEP extension is to be used on parts of a message path, including useragents, origin servers, and proxies, not covered by end-to-end or hop-by-hopextension 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 subsetof proxies in a message path.
It is for the designer of the extension to decide whether it can repeat itselfon a hop-by-hop basis. In other words, any scope more complex than a hop-by-hopor an end-to-end scope is a property of the extension and is transparentto PEP.
This section describes some practical considerations intended for PEP extendedHTTP applications. The issues described may not apply to other informationretrieval protocols.
Extension designers should consider whether an extension is to work withexisting HTTP/1.1 methods using the "PEP-" method token prefix orwith thePEP method (see section 7.1 and 7.2). This specificationdoes not provide an absolute rule for when to use thePEP methodcompared to the "PEP-" method token prefix except that the"PEP-" method token prefix is required in situations where intermediateproxies 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 existingmethods then it should be considered whether the extension can be used withany of the existing HTTP/1.1 methods or only a subset of them.
Some HTTP/1.1 methods follow the convention of being "safe" to the requestermeaning that they should never have the significance of taking an actionother than retrieval (see [7], section 9.1). This is for example the caseof theGET and theHEAD method. As PEP extension declarationsof strength "must" explicitly modify or replace the method name,existing HTTP applications will never be able to mistake a PEP enabled messagefor any of the existing HTTP messages indicated as being safe.
Some extensions may have the property of "idempotence" in that (aside fromerror or expiration issues) the side effects of N > 0 identical extendedrequests is the same as for a single extended request. If this isnotthe case for a PEP extension then it should consider whether it wants to1) disable itself on repeated requests, and/or 2) inform a user about thebehavior of repeating identical requests with this extension.
Designers of extensions to be used within the HTTP messaging model shouldconsider the interaction with existing HTTP/1.1 headers. Especially, it shouldbe noted that PEP is designed to be compatible with HTTP/1.0[5] inasmuchas HTTP/1.1 is compatible with HTTP/1.0 (see [7], section 19.7).
TheConnection header as described in [7], section 14.10, allowsthe sender to specify options that are desired for that particular transportconnection only. All PEP hop-by-hop extension declarations and policies alongwith any header fields introduced by extension declarations MUST be includedasConnection header directives. PEP applications MUST NOT sendany hop-by-hop extension declarations or policies to HTTP/1.0 proxies asthey do not obey the rules of HTTP/1.1 for parsing theConnectionheader field (see also [7], section 19.7.1).
TheUpgrade header, [7], section 14.41, allows the client to specifywhat additional communication protocols it supports and would like to useif the server finds it appropriate to switch protocols. PEP provides thesame functionality but without the need for a central registry of protocolnames. PEP compliant agents MAY use the 101 (Switching Protocols) statuscode to switch to HTTP-based protocols and protocols, which once initiated,run completely independently of HTTP.
The content coding values in theContent-Encoding header as describedin [7], section 14.12, indicate an encoding transformation that has beenapplied to an entity. PEP provides the same functionality but without theneed for a central registry of content codings. As both content codings andPEP extension declarations are ordered, using both may lead to ambiguoussituations. Simultaneous use of both mechanisms is therefore stronglydiscouraged.
An origin server can explicitly prevent intermediaries from applying aContent-Encoding to a resource by using theno-transformCache-Control directive (see [7], section 14.9.4).
PEP extension declarations can be generated by servers as well as clients.If a PEP compliant server sends a response with an extension declarationreferring to an extension that modifies the message in such a way that themessage can not be decoded without using the extension, and the correspondingrequest was either
and the response does not already include anExpires header, thenthe sender SHOULD include anExpires header field whosefield-value is identical to thefield-value of itsDate header field(see [7], section 14.12). If all agents in themessage path are HTTP/1.1, then the sender SHOULD use theCache-Control header field instead of theExpires headerfield to mark the entity uncachable.
The PEP protocol is the product of a substantial amount of investigationand collaboration. Dave Kristol did some of the first writing on HTTP extensionmechanisms[15]. Jim Miller and Dave Raggett sketched out an initial design,which Rohit Khare wrote up in a number of drafts. Tim Berners-Lee, AnselmBaird-Smith, Paul Leach and Daniel Dardailler deserve special recognitionfor their efforts in commenting in the design phase of the protocol. Alsothanks to Henning Schulzrinne, Anup Rao and Robert Lanphier for pointingout the generalities of PEP and providing support for integration with RTSP[12].
This specification is a direct reflection of some implementation work: aclient implementation in [23] (see the HTPEP module) and a server implementationby Eui-Suk Chung and Anit Chakraborty for the JEPI project.
This document has benefited greatly from the comments of all those participatingin the HTTP-WG. In addition to those already mentioned, the following individualshave contributed to this specification:
Dan Connolly
Architecture Domain Lead, World Wide Web Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, U.S.A.
Email: connolly@w3.org
Rohit Khare
Technical Staff, World Wide Web Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, U.S.A.
Email: khare@w3.org
Henrik Frystyk Nielsen
Technical Staff, World Wide Web Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, U.S.A.
Email: frystyk@w3.org
Eric Prud'hommeaux
Contractor, World Wide Web Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, U.S.A.
Email: eric@w3.org
The following tables summarize the outcome of strength and scope rules inPEP transactions involving PEP compliant and non-PEP compliant HTTP proxiesand 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 usedor referenced separately from the complete PEP specification. The tablesshould be read as follows
Table 1: Origin Server
| Scope | Hop-by-hop | End-to-end | ||
|---|---|---|---|---|
| Strength | Optional (may) | Required (must) | Optional (may) | Required (must) |
| PEP not supported | Standard processing | 501 (Not Implemented) | Standard processing | 501 (Not Implemented) |
| Extension not supported | Standard processing | 420 (Policy Not Fulfilled) | Standard processing | 420 (Policy Not Fulfilled) |
| Extension supported | Extended processing | Extended processing | Extended processing | Extended processing |
Table 2: Proxy Server
| Scope | Hop-by-hop | End-to-end | ||
|---|---|---|---|---|
| Strength | Optional (may) | Required (must) | Optional (may) | Required (must) |
| PEP not supported | Strip extension | 501 (Not Implemented) | Forward extension | 501 (Not Implemented) |
| Extension not supported | Strip extension | 420 (Policy Not Fulfilled) | Forward extension | Forward extension |
| Extension supported | Extended processing and strip | Extended processing and strip | Extended processing and strip | Extended processing and strip |
The following examples show various scenarios using PEP in HTTP/1.1 requestsand responses. Information not essential for illustrating the examples isleft out (referred to as "…")
In this example, the purpose of using PEP in the request is to determinewhether a server understands and supports the Distributed Authoring andVersioning (DAV) protocol extension [18]. By making the request binding (seesection 7), the client forces the server to process the extension declarationand obey the extension or report an error.
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" *}} ...The response shows that the server does understand DAV and that the clientcan use it on all resources matching the prefix "/Henrik" on thatserver. The policy is informational and other factors like access controlmay prevent the client from actually using DAV on any of these resources.
PEP does not distinguish between querying about or using an extension –the PEP declaration is identical. Whether it in fact is a query may dependon the request method name and request modifiers.
This example shows a client informing a server that it is capable of handlingthe zipflate compression extension in a response. By issuing an extensionpolicy instead of an extension declaration, the client indicates that theextension is not used in the request.
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: * ...The response shows that the server knows the extension and decides to useit in the response. It furthermore includes theno-transformcache-control directive in order to avoid that proxies add theirowncontent-coding to the message (see section 10.2) and aVary header field indicating that a cache may not use the responseto reply to a subsequent request without revalidation.
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 requestwould not have been affected as the compression applies to message bodiesand not headers. If the request were to include a message body, however,the difference would be whether the zipflate extension was applied to thatbody or not.
This example shows a server applying the Content-Digest extension to a responsemessage indicating that the client may ignore it. The client has not indicatedwhether it supports the extension or even if it supports PEP.
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 ...The response is fully cachable and does not require revalidation when replyingto subsequent requests.
The last example shows how a server requires a client to use a micro-paymentextension in order to access a resource causing an additional roundtrip usingthe 420 (Policy Not Fulfilled) status code (see section 8.1). The first requestdoes not contain any PEP constructs leading to the error message. A non-PEPcompliant client will treat this as a 400 (Bad Request) status code and willnot be able to fulfill the server's requirement in a second request (see[7], section 10.4.1)
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 ...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 properextension declaration. If it did not agree with the price, it could havetried a lower price and depending on the policy of that resource, the servermay have responded positively.
Copyright © 1998W3C(MIT,INRIA,Keio ), All Rights Reserved. W3Cliability,trademark,documentuseandsoftwarelicensingrules apply.