This memo examines the implications of this situation for the operation of HTTP/1.1 origin servers, proxies, and clients, and proposes changes to the HTTP/1.1 specification to permit compliant operation in such systems.
The proposed design uses opaque cache validators and explicit expiration values to allow the server to control the tradeoff between cache performance and staleness of the data presented to users. The server may choose to ensure that a user never unwittingly sees stale data, or to minimize network traffic, or to compromise between these two extremes. The proposed design also allows the server to control whether a client sees stale data after another client performs an update.
This draft is not intended to become a standards-track document. The ultimate output of the HTTP subgroup will be a set of changes to the HTTP/1.1 draft specification [1]. In the interests of making rapid forward progress and in capturing some of the motivation and rationale of our design(s), it seems useful to produce an Internet-draft document in the interim. Note that this draft in its entirety does not currently represent the consensus of the subgroup, although several sections do represent an apparent consensus.
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.
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.
To achieve this behavior, the HTTP WWW-Authenticate header information must be extended. This approach is independent of the authentication scheme, but is most scalable in conjunction with a trusted third party authentication scheme, such as the proposed Mediated Digest Authentication.
This specification is intended as an extension to HTTP/1.1 [4], to be implemented using the negotiation mechanism, transparent content negotiation [5].
This draft is part three of a four part series and explains how to incorporate the RPA mechanism into HTTP. Part one of this series (draft-petke-ext-intro-00.txt) provides an extended introduction to the problems of authentication over insecure networks. Part two (draft-petke-mech-00.txt) explains the RPA mechanism. Part four (draft-petke-serv-deity-protocol-00.txt) explains the protocol between the service and deity.
This scheme was inspired by Dave Raggett's Mediated Digest Authentication paper.