HTTP-WG Historical (Obsolete or Expired) Documents

Old Drafts and Early Papers

Discussion Drafts of Revisions to RFC 2068

These are either already incorporated in the rev-03 draft, or are related to the discussions surrounding what to change in RFC 2068 during the revision to Draft Standard. They are not intended to be stand-alone specifications.
"Format and Example of HTTP/1.1 Requirements Summary",
J. Mogul, 26 Mar 1999.
Text version of <draft-mogul-http-req-sum-00.txt>
RFC1122 [1] introduced a ``Requirements Summary'' format, to help implementors understand what aspects of a lengthy specification were mandatory, recommended, or optional. The HTTP/1.1 specification is similarly lengthy and complicated; many implementors have asked for guidance in understanding what they need to do. The latest draft revision of the HTTP/1.1 specification [2] has a placeholder section for a ``Requirements Summary'', but there has been relatively little discussion of the format and content of this summary in the HTTP working group. This document proposes a specific format for the summary, and gives an example summary for one section of the document.
"Problem with HTTP/1.1 Warning header, and proposed fix",
J. Mogul, A. Luotonen, 19 Mar 1997.
Text version of <draft-ietf-http-warning-00.txt>
The current HTTP/1.1 (RFC2068) specification introduces a new "Warning" header, meant to carry status information about a request that cannot or should not be carried by the response status code. The existing specification for the interaction between Warning and HTTP caches is faulty, in that it may allow incorrect results after cache validation operations. This document identifies two separate (but related) problems, and proposes revisions of the HTTP/1.1 specification to solve these problems.
"Age Header Field in HTTP/1.1",
R. Fielding, 26 Mar 1997.
Text version of <draft-fielding-http-age-00.txt>
The "Age" response-header field in HTTP/1.1 [RFC 2068] is intended to provide a lower-bound for the estimation of a response message's age (time since generation) by explicitly indicating the amount of time that is known to have passed since the response message was retrieved or revalidated. However, there has been considerable controversy over when the Age header field should be added to a response. This document explains the issues and provides a set of proposed changes for the revision of RFC 2068.
"Generation of the Age header field in HTTP/1.1",
J. Mogul, 15 Sep 1997.
Text version of <draft-mogul-http-age-00.txt>
The 'Age' response-header field in HTTP/1.1 [RFC 2068] is intended to provide a lower bound of an estimate of a response message's age (time since generation), by explicitly indicating the amount of time that is known to have passed since the response message was retrieved or revalidated. There has been considerable controversy over when the Age header field should be added to a response. This document explains the issues, rebuts a previous proposal, and provides a set of proposed changes for the revision of RFC 2068.
"HTTP/1.1 305 and 306 Response Codes",
J. Cohen, 16 Jun 1997.
Text version of <draft-cohen-http-305-306-responses-00.txt>
The HTTP/1.1 RFC specifies a response code '305 Use Proxy' which is intended to cause a client to retry the request using a specified proxy server. This functionality is important, but underspecified in the current spec. The spec does not specify for how long or which URLs the redirect applies to, or how proxies can deal with or generate similar responses. This draft proposes a specification for both the 305 response and a new response, "306 Switch Proxy".
"Forcing HTTP/1.1 proxies to revalidate responses",
J. Mogul, 28 May 1997.
Text version of <draft-mogul-http-revalidate-01.txt>
The HTTP/1.1 specification [1] currently defines a ``proxy-revalidate'' Cache-control directive, which forces a proxy to revalidate a stale response before using it in a reply. There is no mechanism defined that forces a proxy, but not an end-client, to revalidate a fresh response. The lack of such a mechanism is due to an error in drafting RFC2068, and appears to create problems for use of the Authorization header, the Digest Access Authentication extension [2], the State Management Mechanism [3], and several other proposed extensions. This document discusses the problem and several possible solutions, and proposes to add a new ``s-maxage'' directive as the best available solution.
"HTTP/1.1 Message Digest Attribute Request",
S. Lawrence, 14 Jul 1997.
Text version of <draft-lawrence-digest-request-00.txt>
This memo describes a security weakness in the current Proposed Standard for HTTP Digest Access Authentication, and proposes a change to that scheme to correct the deficiency. The problem is that there is no mechanism for either party to indicate a requirement that messages be sent with an authentication digest.
"HTTP/1.1 Operation without a Clock",
S. Lawrence, J. Mogul, R. Gray, 22 Apr 1997.
Text version of <draft-lawrence-http-noclock-00.txt>
This memo describes a problem with the current Proposed Standard for HTTP/1.1 found as a result of implementation experience. A web server may be implemented in an embedded system as a network user interface. Often the embedded system is one which has no other use for a real-time clock, and/or the web interface is being added to an existing device which has no clock. Without a clock, no accurate HTTP Date header can be generated.

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.

"Wildcards in the Accept-Charset Header",
K. Holtman, 20 Mar 1997.
Text version of <draft-holtman-http-wildcards-00.txt>
The HTTP/1.1 specification (RFC 2068) defines an Accept-Charset header, but fails to define a wildcard "*" which could be used in this header to match all character sets. This proposal corrects this omission.

Miscellaneous HTTP Internet-Drafts

"HTTP Connection Management",
J. Gettys, A. Freier, 26 Mar 1997.
Text version of <draft-ietf-http-connection-00.txt>
The HTTP/1.1 specification (RFC 2068) is silent about various details of TCP connection management when using persistent connections. This document discusses some of the implementation issues discussed during HTTP/1.1's design, and introduces a few new requirements on HTTP/1.1 implementations learned from implementation experience, not fully understood when RFC 2068 was issued. This is an initial draft for working group comment, and we expect further drafts.
"The User Agent Hint Response Header",
D. Morris, 16 Sep 1997.
Text version of <draft-ietf-http-uahint-01.txt>
This document proposes a HTTP response header called UA-Hint, which can be used by applications (servers) to describe handling hints which will allow user agents to more accurately reflect the intent of the web application designer for the handling and presentation of the response entity. The UA-Hint header is intended to be an extensible general mechanism by which the application can suggest user agent behaviors which alter or extend the behaviors specified in HTTP/1.1 (RFC 2068) with the express purpose of improving the usability of the resulting application. Intended considerations include enablement of a safe POST and refined handling of the traditional history buffer.
"HTTP X-Connfrom header",
J. Mogul, P. Leach, L. Harada, H. Hendren, 15 Sep 1997.
Text version of <draft-harada-http-xconnfrom-01.txt>
HTTP/1.1 defines a Connection header, allowing 'the sender to specify options that are desired for that particular connection and MUST NOT be communicated by proxies over further connections.' Because HTTP/1.0 proxies would normally forward the Connection header without obeying its specification, a Connection header received in an HTTP/1.0 message must normally be treated as if it had been forwarded in error. This document defines an X-Connfrom header that identifies the sending host, and so is safe to use in HTTP/1.0 messages. This might be useful in experimenting with HTTP/1.0 implementations of applications of the HTTP/1.1 Connection mechanism.

Pre-RFC 2068 Products of the Working Group

"Byte Range Retrieval Extension to HTTP",
A. Luotonen, J. Franks, 22 Feb 1996.
Text version of <draft-ietf-http-range-retrieval-00.txt>
It is possible in Web clients to interrupt the connection before the data transfer has finished. As a result the client may have partial documents or images loaded into its memory. It would be useful to be able to request the server to return the missing portion of the document only, instead of retransferring the entire file, if the page is re-entered later.
"A design for caching in HTTP 1.1 Preliminary Draft",
J. Mogul, 19 Feb 1996.
Text version of <draft-mogul-http-caching-00.txt>
I propose a caching design for HTTP 1.1, including the definition of terms, the description of a model, the specification of related HTTP headers, and the algorithms to be used.

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.

"Persistent HTTP Connections",
A. Hopmann, 21 Feb 1996.
Text version of <draft-ietf-http-ses-ext-01.txt>
HTTP was designed to be an extremely lightweight stateless protocol based on TCP. However actual implementation experience suggests that the overhead inherent in establishing a separate TCP connection for every request represents a significant performance problem. This proposal suggests an optional facility for HTTP version 1.1 which allows a client to create persistent connections with a server. This facility is also designed to work with proxy servers.

Proposals by Individuals to the Working Group

"Next Generation Hypertext Transport Protocol", Simon Spero, 26 Mar 1995.
One possiblility for the next generation HTTP protocol.
"A Proposed Extension Mechanism for HTTP",
David M. Kristol, AT&T Bell Laboratories, January 1995.
Text version of <draft-kristol-http-extensions-00.txt>
HTTP, the hypertext transfer protocol, underpins the World-Wide Web (WWW). As the Web has grown, pressures have mounted to add a variety of facilities to HTTP. Some of the new features that have been proposed include: keep-alive, packetized data, compression, security, and payment. This memo offers an alternative: well-defined hooks in a slightly modified HTTP framework that make it possible to add extensions to the basic protocol in a way that will retain compatible behavior between clients and servers, yet allow both clients and servers to discover and use extended capabilities. The goal is to use HTTP as just a transport mechanism, leaving other, higher-level (session) activities to extensions.
"PEP - an Extension Mechanism for HTTP",
H. Nielsen, D. Connolly, R. Khare, E. Prud'hommeaux, 26 Mar 1999.
Text version of <draft-nielsen-pep-http-00.txt>
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.

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.

"Mediated Digest Authentication",
Dave Raggett, 10 Apr 1995.
Text version of <draft-ietf-http-mda-00.txt>
As the number of commercial services on the world wide web increases rapidly, the need arises for a means for these services to authenticate clients, and vice versa. A simple scheme can be based on keyed hash functions with a shared secret key for each client/server pair. Key management becomes impractical for both clients and servers when the number of participants is scaled up. This document describes a efficient scheme for using mutually trusted third parties to mediate authentication, as a direct extension of the digest access authentication scheme. The scheme is based upon public domain algorithms, and unlike encryption software, isn't subject to export restrictions. The main benefits to users include: avoiding having to enter separate user names and passwords for each service, and an ability to authenticate servers. It is proposed that the mediated digest authentication scheme be included in the proposed HTTP/1.1 specification.
"Extended Log File Format",
P. Hallam-Baker, B. Behlendorf, 23 Feb 1996.
Text version of <draft-hallam-http-logfile-00.txt>
An improved format for Web server log files is presented. The format is extensible, permitting a wider range of data to be captured. This proposal is motivated by the need to capture a wider range of data for demographic analysis and also the needs of proxy caches.
"Session Identification URI",
P. Hallam-Baker, D. Connolly, 23 Feb 1996.
Text version of <draft-hallam-http-session-id-00.txt>
Uniform Resource Identifier for identifying HTTP sessions is described. Session identification URIs permit HTTP transactions to be linked within a limited domain. This provides a balance between the needs of commercial servers for demographic data collection and the privacy concerns of users. In addition session identification URIs may be used as part of a high security authentication mechanism to prevent replay attacks.
"Notification for Proxy Caches",
P. Hallam-Baker, 23 Feb 1996.
Text version of <draft-hallam-http-proxy-note-00.txt>
A mechanism to enable better functioning of proxies is proposed. This mechanism allows proxies to inform a remote server about transactions performed using the cache and for servers to inform proxies when data becomes stale.
"An Extension of the HTTP Authentication Scheme To Support Server Groups",
A. Hutchison, M. Kaiserswerth, P. Trommler, 20 Mar 1996.
Text version of <draft-trommler-http-ext-groups-00.txt>
This document motivates and describes an extension to HTTP which allows protection spaces to be extended across multiple servers residing in possibly different domains. These servers form groups that allow browsers to obtain authentication information from a user just once while accessing information on any one server cooperating in such a group.

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.

"User-Agent Display Attributes Headers",
A. Mutz, L. Montulli, L. Masinter, K. Holtman, 26 Nov 1996.
Text version of <draft-mutz-http-attributes-02.txt>
User-Agent Display Attributes Headers provide a means for an HTTP client [3] and server to negotiate for content dependent on the client display capabilities. This memo describes feature tags for introducing this information into an HTTP transmission. The intent is to present resource variants when available [5] such that a capable server may present documents in a preferred form to a client. If such a preferred form is not available, the server should still provide the requested documents.

This specification is intended as an extension to HTTP/1.1 [4], to be implemented using the negotiation mechanism, transparent content negotiation [5].

"HTTP-based SNMP and CMIP Network Management",
L. Deri, 19 Nov 1996.
Text version of <draft-deri-http-mgmt-00.txt>
This document describes the application of the HyperText Transfer Protocol (HTTP) [HTTP] for the purpose of SNMP [SNMP] and CMIP [CMIP] management. It shows how SNMP and CMIP resources can be managed by using the standard HTTP protocol by defining a mapping between SNMP/CMIP protocols and HTTP. The mapping is very simple and based on strings which can easily be handled by any programming and scripting language. This will allow light and simple HTTP-based applications to be created, since they have not to include any management service like encoding/decoding nor to handle complex data types.
"Remote Passphrase Authentication Part Three: HTTP Authentication Scheme",
G. Brown, 15 Nov 1996.
Text version of <draft-petke-http-auth-scheme-00.txt>
Remote Passphrase Authentication provides a way to authenticate a user to a service by using a pass phrase over an insecure network, without revealing the pass phrase to eavesdroppers. In addition, the service need not know and does not learn the user's pass phrase, making this scheme useful in distributed environments where it would be difficult or inappropriate to trust a service with a pass phrase database or to allow the server to learn enough to masquerade as the user in a future authentication attempt.

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.

IETF HTTP Working Group
Roy Fielding Department of Information and Computer Science
University of California, Irvine, CA 92697-3425
Last modified: 27 Apr 1999