IETF
Hypertext Transfer Protocol (HTTP) Working Group

Note that this is an old archive from 1994-1996 and will have a lot of broken links. If you just want to look at the old drafts, they are in the history of HTTP drafts.

Mailing List and Archives

Discussion of these and related topics takes place on the HTTP working group mailing list.

IESG Internet-Drafts

"On the use of HTTP as a Substrate for Other Protocols",
K. Moore, P. Faltstrom, 06 Aug 1998.
Text version of <draft-iesg-using-http-00.txt>
Abstract
Recently there has been widespread interest in using Hypertext Transport Protocol (HTTP) as a substrate for other applications-level protocols. This document relates current IESG and IAB thinking on technical particulars of such use, including use of default ports, URL schemes, and HTTP security mechanisms. This thinking is subject to change as discussion continues and more experience is gained with such use.
"Use of HTTP State Management",
K. Moore, N. Freed, 07 Dec 1999.
Text version of <draft-iesg-http-cookies-02.txt>
Abstract
The mechanisms described in 'HTTP State Management Mechanism' [RFC-XXXX] and its predecessor [RFC-2109] can be used for many different purposes. However, some current and potential uses of the protocol are controversial because they have significant user privacy and security implications. This memo identifies specific uses of HTTP State Management protocol which are either (a) not recommended by the IETF, or (b) believed to be harmful, and discouraged. This memo also details additional privacy considerations which are not covered by the HTTP State Management protocol specification.

Primary HTTP-WG Internet-Drafts

"HTTP State Management Mechanism",
D. Kristol, L. Montulli, 30 Aug 1999.
Text version of <draft-ietf-http-state-man-mec-12.txt>
Abstract
This document specifies a way to create a stateful session with HTTP requests and responses. It describes two new headers, Cookie and Set- Cookie2, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal [Netscape], but it can interoperate with HTTP/1.0 user agents that use Netscape's method. (See the HISTORICAL section.)

This document reflects implementation experience with RFC 2109 [RFC2109] and obsoletes it.

HTTP Extension Mechanisms

Apparently this is not a working group, but is being discussed on the HTTP-EXT mailing list.
"Specification of HTTP/1.1 OPTIONS messages",
J. Mogul, S. Lawrence, J. Cohen, 29 Aug 1997.
Text version of <draft-ietf-http-options-02.txt>
Abstract
RFC2068 defined a new OPTIONS method for HTTP/1.1. The purpose of OPTIONS is to allow a 'client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.' However, RFC2068 did not defined a specific syntax for using OPTIONS to make such a determination. This proposal clarifies the original specification of OPTIONS, adds several new HTTP message headers to provide syntactic support for OPTIONS, and establishes new IANA registries to avoid namespace conflicts.
"Assignment of Status Codes for HTTP and HTTP-Derived Protocols",
H. Schulzrinne, 01 Aug 1997.
Text version of <draft-schulzrinne-http-status-00.txt>
Abstract
A number of other protocols may make use of HTTP syntax and facilities; this memo defines a mechanism for IANA to allocate status codes.
"Don't Go Postal - An argument against improperly overloading the HTTP POST Method",
J. Cohen et al., 16 Feb 1998.
Text version of <draft-cohen-http-ext-postal-00.txt>
Abstract
As time goes on, more and more groups are extending HTTP's functionality. In using HTTP, a decision is made to either use a new method name for new functionality or to overload an existing one such as POST. Our belief is that in most cases, overloading existing method names, with POST as a particularly troublesome example, is a bad idea. We, as a group of individuals, suggest that the default requirement for new HTTP functionality must be to create a new method name.
"The Use of Post: A Response to draft-cohen-http-postal-00.txt",
Roger deBry, Carl Kugler, Stee Gebert, Harry Lewis, Don Wright, Scott Isaacson, Tom Hasting, 24 Feb 1998.
Text version of <draft-debry-http-usepost-00.txt>
Abstract
A recent Internet Draft [1] argues that the common use of POST to provide a uniform method of passing blocks of data to an application, is being misused in the definition of new application protocols, such as the Internet Printing Protocol. Cohen et. al. argue that a new PUSH method be defined for this purpose. This Internet Draft argues that the existing POST method proides all of the required functionality for back end applications, such as Print, without sacrificing the levels of security that customers expect. More importantly, from the customer's point of view, it does this without any impact to existing, installed network components.

Content Negotiation

This has now been assigned to the new Content Negotiation (conneg) working group.
"Scenarios for the Delivery of Negotiated Content using HTTP",
E. Hardie, 15 Jul 1997.
Text version of <draft-ietf-http-negotiate-scenario-02.txt>
Abstract
A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact. While MIME media types [1] provide a standard method for handling one major axis of variation, resources also vary in ways which cannot be expressed using currently available MIME headers. This paper asserts that a cross-protocol negotiation framework is needed, both to leverage work already done for specific protocols and to allow for content negotiation when resources will pass through several protocols on their way from provider to recipient. To justify the need, this paper puts forward several content negotiation scenarios and discusses how they affect the requirements for such a framework.
"The Alternates Header Field",
K. Holtman, A. Mutz, 13 Nov 1997.
Text version of <draft-ietf-http-alternates-01.txt>
Abstract
This document proposes a header, Alternates, which is intended to provide a common method for Internet-based application protocols to indicate that a particular resource exists in multiple forms. The Alternates header provides a machine-readable indication of the bases on which the different forms vary and how the the recipient of the header can select among them.
"Feature Tag Scenarios",
K. Holtman, A. Mutz, 28 Jul 1997.
Text version of <draft-ietf-http-feature-scenarios-01.txt>
Abstract
Recent Internet applications, such as the World Wide Web, tie together a great diversity in data formats, client and server platforms, and communities. This has created a need for various kinds of negotiation mechanisms, which tailor the data which is exchanged, or the exchange process itself, to the capabilities and preferences of the parties involved.

Extensible negotiation mechanisms need a vocabulary to identify various things which can be negotiated on. To promote interoperability, a registration process is needed to ensure that that this vocabulary, which can be shared between negotiation mechanisms, is developed in an orderly, well-specified, and public manner.

This document discusses requirements and scenarios the registration of this vocabulary, which is the vocabulary of feature tags. Feature tag registration is foreseen as an ongoing, open process which will keep pace with the introduction of new features by software vendors, and other parties such as standards bodies.

"Corrections to 'A syntax for describing media feature sets",
G. Klyne, 27 Apr 1999.
Text version of <draft-ietf-conneg-feature-syntax-er-00.txt>
Abstract
In RFC 2533,'A syntax for describing media feature sets', an expression format is presented for describing media feature capabilities using simple media feature tags.

This memo contains two corrections to that specification: one fixes an error in the formal syntax specification, and the other fixes an error in the rules for reducing feature comparison predicates.

"An algebra for describing media feature sets",
G. Klyne, 07 Aug 1998.
Text version of <draft-ietf-conneg-feature-algebra-03.txt>
Abstract
A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact [1]. A framework for such negotiation is described in [2]. Part of this framework is a way to describe the range of media features which can be handled by the sender, recipient or document transmission format of a message. A format for a vocabulary of individual media features and procedures for registering media features are presented in [3].

This document describes an algebra and syntax that can be used to define feature sets which are formed from combinations and relations involving individual media features. Such feature sets are used to describe the media feature handling capabilities of message senders, recipients and file formats.

This document also outlines an algorithm for feature set matching.

"W3C Composite Capability/Preference Profiles",
G. Klyne, 14 Jan 2000.
Text version of <draft-klyne-conneg-W3C-ccpp-00.txt>
Abstract
This document suggests some possible areas for extending the IETF 'conneg' working group's capability description framework, described in [2,3,4]. The suggested areas for extension have been motivated by WWW Consortium (W3C) work on Composite Capability/Preference Profiles (CCPP) [5] that parallels some aspects of the IETF 'conneg' work.

This is presented as a discussion document, with a view to maybe integrating some of these ideas into ongoing 'conneg' work, and to indicate some areas for ongoing collaboration between the IETF and W3C in the area of content description.

"Indicating media features for MIME content",
G. Klyne, 30 Nov 1999.
Text version of <draft-ietf-conneg-content-features-02.txt>
Abstract
In 'A syntax for describing media feature sets', an expression format is presented for describing media feature capabilities using simple media feature tags.

This memo defines a MIME 'Content-features:' header that can be used to annotate a MIME message part using this expression format, and indicates some ways it might be used.

"MIME content types in media feature expressions",
G. Klyne, 30 Nov 1999.
Text version of <draft-ietf-conneg-feature-type-02.txt>
Abstract
In RFC 2533, 'A syntax for describing media feature sets', an expression format is presented for describing media feature capabilities using simple media feature tags.

This memo defines a media feature tag whose value is a MIME content type. This allows the construction of feature expressions that take account of the MIME content type of the corresponding data.

"Identifying composite media features",
G. Klyne, L. Masinter, 07 Sep 1999.
Text version of <draft-ietf-conneg-feature-hash-03.txt>
Abstract
In RFC 2533 [1], an expression format is presented for describing media feature capabilities as a combination of simple media feature tags [2].

This document describes an abbreviated format for a composite media feature set, based upon a hash of the feature expression describing that composite, or the URI of a resource containing the feature expression.

"Syntax extensions for abbreviating media feature sets with URLs",
W. Newman, 01 Mar 1999.
Text version of <draft-ietf-conneg-feature-sets-at-urls-00.txt>
Abstract
This document describes an extension to the CONNEG syntax[SYNTAX] which allows a feature set expression to be represented as an absolute URL, which can then be looked up over another channel, which is not necessarily the channel between the negotiating parties. By using this extension, content negotiation between two parties can proceed with a relatively small exchange of data over the channel between them. Of course, the contents of the URL must still be found through some channel. However, the channel used to find the contents of the URL may have greater bandwidth than the channel between the negotiating parties, and may further benefit from HTTP or other caching mechanisms.
"A revised media feature set matching algorithm",
G. Klyne, 18 Jun 1999.
Text version of <draft-klyne-conneg-feature-match-00.txt>
Abstract
RFC 2533,'A syntax for describing media feature sets', defines a format to express media feature sets that represent media handling capabilities. It also describes an algorithm for matching these feature sets, which may be used, for example, to determine whether the capabilities of a sender and receiver are compatible.

Miscellaneous HTTP Internet-Drafts

"Use of the Content-Disposition header with HTTP",
C. Faerber, 22 Sep 1998.
Text version of <draft-faerber-http-content-disp-00.txt>
Abstract
[RFC2183] introduces a Content-Disposition header field for Internet Mail Messages to transmit presentation information as well as a suggested file name for saving the content to disk and the file's date information.

All of this information is missing from HTTP entities [RFC2068]. However, there is nothing that would prevent the use of the Content- Disposition header with this HTTP.

Without being standard, the Content-Disposition header has already been introduced by some software products. [HTTP1.1-REV] documents this practice, based on [RFC1806].

This memo also extends the specification to cover [RFC2183] and corrects the common abuse of the Content-Type header to cover presentation information.

"Format and Example of HTTP/1.1 Requirements Summary",
J. Mogul, 26 Mar 1999.
Text version of <draft-mogul-http-req-sum-00.txt>
Abstract
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.
"Instance Digests in HTTP",
J. Mogul, A. van Hoff, 19 Feb 1998.
Text version of <draft-mogul-http-digest-01.txt>
Abstract
HTTP/1.1 defines a Content-MD5 header that allows a server to include a digest of the response body. However, this is specifically defined to cover the body of the actual message, not the contents of the full file (which might be quite different, if the response is a Content-Range, or uses a delta encoding). Also, the Content-MD5 is limited to one specific digest algorithm; other algorithms, such as SHA-1, may be more appropriate in some circumstances. Finally, HTTP/1.1 provides no explicit mechanism by which a client may request a digest. This document proposes HTTP extensions that solve these problems.
"Delta encoding in HTTP",
J. Mogul, B. Krishnamurthy, F. Douglis, A. Feldmann, Y. Goland, A. van Hoff, 20 Oct 1999.
Text version of <draft-mogul-http-delta-02.txt>
Abstract
Many HTTP requests cause the retrieval of slightly modified instances of resources for which the client already has a cache entry. Research has shown that such modifying updates are frequent, and that the modifications are typically much smaller than the actual entity. In such cases, HTTP would make more efficient use of network bandwidth if it could transfer a minimal description of the changes, rather than the entire new instance of the resource. This is called 'delta encoding.' This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1.
"HTTP Proxy State Management Mechanism",
D. Kristol, 27 May 1998.
Text version of <draft-kristol-http-proxy-state-00.txt>
Abstract
This document specifies a way to create a stateful session, using HTTP requests and responses, between an HTTP proxy server and its client. It describes two new headers, Pcookie and Set-Pcookie, which carry state information between participating HTTP proxy servers and their clients.
"Using the Transaction Internet Protocol (TIP) with HTTP",
Y. Goland, 02 Feb 1998.
Text version of <draft-ietf-tip-usehttp-01.txt>
Abstract
This specification defines how to use Transaction Internet Protocol (TIP) URLs to transaction arbitrary HTTP communications.
"HTTP Over TLS",
E. Rescorla, 09 Sep 1999.
Text version of <draft-ietf-tls-https-03.txt>
Abstract
This memo describes how to use TLS to secure HTTP connections over the Internet. Current practice is to layer HTTP over SSL (the prede- cessor to TLS), distinguishing secured traffic from insecure traffic by the use of a different server port. This document documents that practice using TLS. A companion document describes a method for using HTTP/TLS over the same port as normal HTTP.
"HTTP over TLS using a TCP Filter",
G. Belingueres, 23 Nov 1999.
Text version of <draft-belingueres-http-tls-filter-00.txt>
Abstract
This document explains how to use the TCP Security Filter mechanism to initiate a Transport Layer Security (TLS) session to secure HTTP connections over the Internet. This allows unsecured and secured HTTP traffic to share the same well known port (in this case, http: at 80 rather than https: at 443). As an additional point, a similar mechanism like the described here could be used to provide other different kind of layers to HTTP connections.
"WIRE - W3 Identifier Resolution",
L. Girod, B. Chen, H. Frystyk, J. Mallery, 16 Mar 1998.
Text version of <draft-girod-w3-id-res-ext-00.txt>
Abstract
WIRE extends HTTP with a new type of redirect response that permits a resolver to explicitly delegate a resolution to other resolvers and protocols. WIRE is an effort to make delegation more explicit, redirection more flexible, and resolution processes more efficient through the use of hints. This document defines WIRE and describes the expected behaviors of resolvers and clients using WIRE. WIRE is an extension of the HyperText Transfer Protocol (HTTP), and is intended to be compatible with HTTP/1.0 and above [4][5].

WIRE encourages use of long-lived URIs and at the same time supports protocol evolution without having to change currently deployed URIs or URI schemes. The extension is based on a simple URI resolution model that allows an application to dynamically request metadata describing where and how to access a resource. The model can use any generic metadata description language (e.g. RDF) and as the metadata itself is interpreted as a first class resource, metadata resources are no different than any other resource on the Web.

"Duplicate Suppression in HTTP",
J. Mogul, A. van Hoff, 16 Apr 1998.
Text version of <draft-mogul-http-dupsup-00.txt>
Abstract
A significant fraction of Web content is often exactly duplicated under several different URIs. This duplication can lead to suboptimal use of network bandwidth, and unnecessary latency for users. Much of this duplication can be avoided through the use of a simple mechanism, described here, which allows a cache to efficiently substitute one byte-for-byte identical value for another. By doing so, the cache avoids some or all of the network costs associated with retrieving the duplicate value.
"Access-restricted, HTTP/1.1 Cache Control Extension",
I. Melve, S. Wilkinson, 12 Mar 1998.
Text version of <draft-melve-cachecontrol-00.txt>
Abstract
User agents such as caches and web indexers, which act on behalf of more than one user are often given access to documents which are restricted by IP address or domain. These agents then republish this information to users outside the allowed block, as there is currently no means of marking these objects with their access restrictions.

This document details an extension to the Cache-control header in HTTP/1.1 [HTTP/1.1] to add information about IP or domain based access restrictions. It also stresses that Cache-control should apply to all User-agents which work on behalf on a number of users, and not just to caches.

"Hyper Text Caching Protocol (HTCP/0.0)",
P. Vixie, 05 Mar 1998.
Text version of <draft-vixie-htcp-proto-00.txt>
Abstract
This draft describes HTCP, a protocol for discovering HTTP caches and cached data, managing sets of HTTP caches, and monitoring cache activity.
"Cachebusting - cause and prevention",
M. Hamilton, A. Daviel, 14 Jan 1999.
Text version of <draft-hamilton-cachebusting-01.txt>
Abstract
Cachebusting is the sometimes deliberate, sometimes inadvertant, practice of defeating caching. This document explains the nature of the problem with relation to proxy cache servers using the World-Wide Web's HTTP protocol, and outlines some simple measures which may be taken to make an HTTP based service more 'cache friendly'. Since Web caching is still a novel concept, we also explain the basic principles behind it. This document should be read by developers of HTTP based products and services - we assume that the reader is already familiar with HTTP.
"HTTP Trust Mechanism for State Management",
D. Jaye, 26 Mar 1999.
Text version of <draft-jaye-http-trust-state-mgt-00.txt>
Abstract
This document specifies an addition to the state management protocol specified in draft-ietf-http-state-man-mec-08[Kristol]. The intent is to provide a mechanism that allows user agents to determine the privacy practices of a server and to accept or reject cookies based on those practices. Allowing the user to establish preferences for how to handle cookies based on the server's practices provides a practical mechanism to provide users control over the privacy implications of cookies.

To provide verification of server privacy practices, we assume the existence of one or more independent Trust Authorities. The authority establishes PICS ratings representing server privacy practices. It then issues trust-labels, in the form of digitally signed PICS labels, to organizations for specific domains and paths based on the server privacy practices. The Trust Authority must be able to audit domains to verify their adherence to a given level. Passing these trust-labels along with cookies allows the user agent to support cookie handling preferences based on trusted privacy practices.

This document describes how PICS-headers are used in conjunction with Set-Cookie or Set-Cookie2 headers in [Kristol] to provide trust-labels to communicate the privacy practices of servers regarding cookies.

"Using Digest Authentication as a SASL Mechanism",
P. Leach, C. Newman, 02 Oct 1998.
Text version of <draft-leach-digest-sasl-00.txt>
Abstract
This specification defines how HTTP Digest Authentication [Digest] can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5 [RFC2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols.
"Handling of fragment identifiers in redirected URLs",
B. Bos, 19 Jul 1999.
Text version of <draft-bos-http-redirect-00.txt>
Abstract
The HTTP 1.1 specification describes how a server can answer a request with a redirection, instructing the client to get the resource from a different URL. It doesn't explain what to do with any fragment identifier that might have been on the original URL, and this omission has resulted in different clients handling fragments in different ways. This draft gives rules towards a more consistent handling by future HTTP clients.
"Experiences with HTTP-SELECT and Asynchronous Updates",
K. Wolf, 30 Jun 1999.
Text version of <draft-wolf-http-select-00.txt>
Abstract
Many Internet services need asynchronous notifications. At the same time there is an increasing number of protocols which use HTTP or HTTP-alike request-response transactions. This document proposes an extension to application protocols which enables asynchronous notifications from server to client through client initiated request-response transactions. The extension applies the Unix select() pattern to TCP connections of HTTP-alike protocols. Hence it is called HTTP-SELECT.
"General Event Notification Architecture Base: Client to Arbiter",
J. Cohen, S. Aggarwal, Y. Goland, 25 Jun 1999.
Text version of <draft-cohen-gena-client-00.txt>
Abstract
This document provides for the ability to send and receive notifications using HTTP over TCP/IP and administratively scoped unreliable multicast UDP. Provisions are made for the use of intermediary arbiters, called subscription arbiters, which handle routing notifications to their intended destination.
"Multicast and Unicast UDP HTTP Messages",
Y. Goland, 11 Nov 1999.
Text version of <draft-goland-http-udp-01.txt>
Abstract
This document provides rules for encapsulating HTTP messages in Multicast and Unicast UDP packets to be sent within a single administrative scope. No provisions are made for guaranteeing delivery beyond re-broadcasting.
"SOAP: Simple Object Access Protocol",
D. Box, G. Kakivaya, A. Layman, S. Thatte, D. Winer, 13 Sep 1999.
Text version of <draft-box-http-soap-00.txt>
Abstract
SOAP defines an RPC mechanism using XML for client-server interaction across a network by using the following mechanisms:
* HTTP as the base transport
* XML documents for encoding of invocation requests and responses
"Server-Side Roles in the HTTP",
M. Nottingham, 30 Aug 1999.
Text version of <draft-nottingham-http-roles-00.txt>
Abstract
Web servers are becoming more complex, and as a result are losing the full benefits of HTTP protocol compliance.

This applicability statement defines classifications of Web server sub-components and clarifies their responsibilities in implementing HTTP/1.1 protocol features, with a discussion of the motivations for doing so.

"Geographic extensions for HTTP transactions",
A. Daviel, 10 Sep 1999.
Text version of <draft-daviel-http-geo-header-00.txt>
Abstract
This memo describes a method of adding simple geographic position information to HTTP transactions using extension headers. In the case of an HTTP request, the extensions indicate a geographic position or region that the requesting agent is interested in. This information may be used by a server to present appropriate position- dependant responses, such as search engine results, without the additional overhead of geographic query requests. In the case of an HTTP response, the extensions indicate a geographic position or region relevant to the resource described in the body of the response. This information may be used for automated resource discovery.

Requests for Comments

RFC 1945. Informational
"Hypertext Transfer Protocol -- HTTP/1.0",
T. Berners-Lee, R. Fielding, and H. Frystyk, May 1996.
Also available in plain text, HTML, and PostScript (gzip'd) formats.
Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods (commands). A feature of HTTP is the typing of data representation, allowing systems to be built independently of the data being transferred.

HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification reflects common usage of the protocol referred to as "HTTP/1.0".

RFC 2068. Obsoleted by RFC 2616
"Hypertext Transfer Protocol -- HTTP/1.1",
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, January 1997.
Also available in PostScript (gzip'd) format.
Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.

HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1".

RFC 2069. Obsoleted by RFC 2617
"An Extension to HTTP: Digest Access Authentication",
Jeffery L. Hostetler, John Franks, Phillip Hallam-Baker, Paul Leach, Ari Luotonen, Eric W. Sink, Lawrence C. Stewart, January 1997.
Abstract
The protocol referred to as "HTTP/1.0" includes the specification for a Basic Access Authentication scheme. This scheme is not considered to be a secure method of user authentication, as the user name and password are passed over the network as clear text. A specification for a different authentication scheme is needed to address this severe limitation. This document provides specification for such a scheme, referred to as "Digest Access Authentication". Like Basic, Digest access authentication verifies that both parties to a communication know a shared secret (a password); unlike Basic, this verification can be done without sending the password in the clear, which is Basic's biggest weakness. As with most other authentication protocols, the greatest sources of risks are usually found not in the core protocol itself but in policies and procedures surrounding its use.
RFC 2109. Proposed Standard
"HTTP State Management Mechanism",
D. Kristol, L. Montulli, February 1997.
Abstract
This document specifies a way to create a stateful session with HTTP requests and responses. It describes two new headers, Cookie and Set-Cookie, which carry state information between participating origin servers and user agents.
RFC 2145. Informational
"Use and Interpretation of HTTP Version Numbers",
J. C. Mogul, R. Fielding, J. Gettys, H. Frystyk, May 1997.
Abstract
HTTP request and response messages include an HTTP protocol version number. Some confusion exists concerning the proper use and interpretation of HTTP version numbers, and concerning interoperability of HTTP implementations of different protocol versions. This document is an attempt to clarify the situation.
RFC 2227. Proposed Standard
"Simple Hit-Metering and Usage-Limiting for HTTP",
J. Mogul, P. Leach, October 1997.
Abstract
This document proposes a simple extension to HTTP, using a new "Meter" header, which permits a limited form of demographic information (colloquially called "hit-counts") to be reported by caches to origin servers, in a more efficient manner than the "cache-busting" techniques currently used. It also permits an origin server to control the number of times a cache uses a cached response, and outlines a technique that origin servers can use to capture referral information without "cache-busting."
RFC 2295. Experimental
"Transparent Content Negotiation in HTTP",
K. Holtman, A. Mutz, March 1998.
Abstract
HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags.
RFC 2296. Experimental
"HTTP Remote Variant Selection Algorithm -- RVSA/1.0",
K. Holtman, A. Mutz, March 1998.
Abstract
HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is a mechanism for automatically selecting the best version when the URL is accessed. A remote variant selection algorithm can be used to speed up the transparent negotiation process. This document defines the remote variant selection algorithm with the version number 1.0.
RFC 2310. Experimental
"The Safe Response Header Field",
K. Holtman, April 1998.
Abstract
This document defines a HTTP response header field called Safe, which can be used to indicate that repeating a HTTP request is safe. Such an indication will allow user agents to handle retries of some safe requests, in particular safe POST requests, in a more user-friendly way.
RFC 2506. Best Current Practice
"Media Feature Tag Registration Procedure",
K. Holtman, A. Mutz, T. Hardie, March 1999.
Abstract
Recent Internet applications, such as the World Wide Web, tie together a great diversity in data formats, client and server platforms, and communities. This has created a need for media feature descriptions and negotiation mechanisms in order to identify and reconcile the form of information to the capabilities and preferences of the parties involved.

Extensible media feature identification and negotiation mechanisms require a common vocabulary in order to positively identify media features. A registration process and authority for media features is defined with the intent of sharing this vocabulary between communicating parties. In addition, a URI tree is defined to enable sharing of media feature definitions without registration.

This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary.

RFC 2533. Proposed Standard
"A Syntax for Describing Media Feature Sets",
G. Klyne, March 1999.
Abstract
A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact [1]. A framework for such negotiation is described in [2], part of which is a way to describe the range of media features which can be handled by the sender, recipient or document transmission format of a message. A format for a vocabulary of individual media features and procedures for feature registration are presented in [3].

This document introduces and describes a syntax that can be used to define feature sets which are formed from combinations and relations involving individual media features. Such feature sets are used to describe the media feature handling capabilities of message senders, recipients and file formats.

An algorithm for feature set matching is also described here.

RFC 2534. Proposed Standard
"Media Features for Display, Print, and Fax",
L. Masinter, D. Wing, A. Mutz, K. Holtman, March 1999.
Abstract
This specification defines some common media features for describing image resolution, size, color, and image representation methods that are common to web browsing, printing, and facsimile applications. These features are registered for use within the framework of [REG].
RFC 2616 [pdf, html]. Draft Standard
"Hypertext Transfer Protocol -- HTTP/1.1",
R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk Nielsen, L. Masinter, P. Leach, T. Berners-Lee, June 1999.
Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.

HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068 [33].

RFC 2617. Draft Standard
"HTTP Authentication: Basic and Digest Access Authentication",
J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, L. Stewart, June 1999.
Abstract
"HTTP/1.0", includes the specification for a Basic Access Authentication scheme. This scheme is not considered to be a secure method of user authentication (unless used in conjunction with some external secure system such as SSL [5]), as the user name and password are passed over the network as cleartext.

This document also provides the specification for HTTP's authentication framework, the original Basic authentication scheme and a scheme based on cryptographic hashes, referred to as "Digest Access Authentication". It is therefore also intended to serve as a replacement for RFC 2069 [6]. Some optional elements specified by RFC 2069 have been removed from this specification due to problems found since its publication; other new elements have been added for compatibility, those new elements have been made optional, but are strongly recommended.

RFC 2703. Informational
"Protocol-independent content negotiation framework",
G. Klyne, September 1999.
Abstract
A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact. MIME media types [1,2] provide a standard method for handling one major axis of variation, but resources also vary in ways which cannot be expressed using currently available MIME headers.

This memo sets out terminology, an abstract framework and goals for protocol-independent content negotiation, and identifies some technical issues which may need to be addressed.

The abstract framework does not attempt to specify the content negotiation process, but gives an indication of the anticipated scope and form of any such specification. The goals set out the desired properties of a content negotiation mechanism.

RFC 2774. Experimental
"HTTP Extension Framework",
H. Frystyk Nielsen, P. Leach, S. Lawrence, February 2000.
Abstract
A wide range of applications have proposed various extensions of the HTTP protocol. Current efforts span an enormous range, including distributed authoring, collaboration, printing, and remote procedure call mechanisms. These HTTP extensions are not coordinated, since there has been no standard framework for defining extensions and thus, separation of concerns. This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. The proposal associates each extension with a globally unique identifier, and uses HTTP header fields to carry the extension identifier and related information between the parties involved in the extended communication.
"Upgrading to TLS Within HTTP/1.1",
R. Khare, S. Lawrence, February 2000.
Text version of <draft-ietf-tls-http-upgrade-05.txt>
Abstract
This memo explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. This allows unsecured and secured HTTP traffic to share the same well known port (in this case, http: at 80 rather than https: at 443). It also enables 'virtual hosting,' so a single HTTP + TLS server can disambiguate traffic intended for several hostnames at a single IP address.

Since HTTP/1.1[1] defines Upgrade as a hop-by-hop mechanism, this memo also documents the HTTP CONNECT method for establishing end-to-end tunnels across HTTP proxies. Finally, this memo establishes new IANA registries for public HTTP status codes, as well as public or private Upgrade product tokens.


Related Work

Roy T. Fielding