IETF
Hypertext Transfer Protocol (HTTP) Working Group

Special Notice: Due to a combination of Xmas site shutdown and physical re-location of the list server, the http-wg@cuckoo.hpl.hp.com mailing list will be unavailable from the 18th of December until the 5th of January.

As a service, W3C has set up ietf-http-wg@w3.org as a temporary mailing list for HTTP Working Group discussions that can be used until the normal list is up and running again. Unfortunately, you will have to subscribe to it even if you are already subbscribed to the normal list.


Mailing List and Archives

Discussion of these and related topics takes place on the HTTP working group mailing list <http-wg@cuckoo.hpl.hp.com>. To subscribe to the mailing list, send a message containing the word "subscribe" as the subject to the request address <http-wg-request@cuckoo.hpl.hp.com>. A hypertext archive of the mailing list is available at UCI and also at FindMail.

Meeting Notes

Current HTTP-WG Internet-Drafts

"Hypertext Transfer Protocol -- HTTP/1.1",
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, 26 Nov 1997.
<draft-ietf-http-v11-spec-rev-01> as text, or gzip'd Word97 or PostScript.
Additional information is available on the Issues list.
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''.

"HTTP Authentication: Basic and Digest Access Authentication",
J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, E. Sink, L. Stewart, 26 Nov 1997.
Text version of <draft-ietf-http-authentication-00.txt>
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 clear text.

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 intended to also serve as a replacement for RFC 2069.[6]

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.

"Format and Example of HTTP/1.1 Requirements Summary",
J. Mogul, 15 Sep 1997.
Text version of <draft-ietf-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.
"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>
Abstract
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.
"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.
"HTTP State Management Mechanism",
D. Kristol, L. Montulli, 26 Nov 1997.
Text version of <draft-ietf-http-state-man-mec-05.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, 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 and obsoletes it.

"PEP - an Extension Mechanism for HTTP",
H. Frystyk Nielsen, D. Connolly, R. Khare, E. Prud'hommeaux, 04 Dec 1997.
Text version of <draft-ietf-http-pep-05.txt>
Abstract
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.
"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.
"Transparent Content Negotiation in HTTP",
K. Holtman, A. Mutz, 15 Sep 1997.
Text version of <draft-ietf-http-negotiation-04.txt>
Additional information is available at Koen's site.
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.
"HTTP Remote Variant Selection Algorithm -- RVSA/1.0",
K. Holtman, A. Mutz, 28 Jul 1997.
Text version of <draft-ietf-http-rvsa-v10-02.txt>
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.
"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.

"Feature Tag Registration Procedures",
K. Holtman, A. Mutz, 28 Jul 1997.
Text version of <draft-ietf-http-feature-reg-02.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, 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 defines registration procedures which use the Internet Assigned Numbers Authority (IANA) as a central registry for this vocabulary, which is the vocabulary of feature tags.

Internet-Drafts by Individuals for HTTP

These are Internet-Draft documents that individuals have produced and not (yet) assigned as WG tasks. Their presence here does not imply that the ideas or mechanisms contained within the drafts are endorsed by the WG, nor that they will appear in some future version of HTTP.
Note: These documents should be named "draft-author-http-..." in order to avoid confusion with documents edited under the direction of the WG as a whole.
"Age Header Field in HTTP/1.1",
R. Fielding, 26 Mar 1997.
Text version of <draft-fielding-http-age-00.txt>
Abstract
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>
Abstract
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>
Abstract
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".
"HTTP Connection Management",
J. Gettys, A. Freier, 26 Mar 1997.
Text version of <draft-ietf-http-connection-00.txt>
Abstract
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.
"Forcing HTTP/1.1 proxies to revalidate responses",
J. Mogul, 28 May 1997.
Text version of <draft-mogul-http-revalidate-01.txt>
Abstract
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>
Abstract
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>
Abstract
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>
Abstract
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.
"The Safe Response Header Field",
K. Holtman, 10 Sep 1997.
Text version of <draft-holtman-http-safe-03.txt>
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.
"The User Agent Hint Response Header",
D. Morris, 16 Sep 1997.
Text version of <draft-ietf-http-uahint-01.txt>
Abstract
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>
Abstract
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.
"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.
"HTTP Trust Mechanism for State Management",
D. Jaye, 27 Oct 1997.
Text version of <draft-ietf-http-jaye-trust-state-01.txt>
Abstract
This document specifies an addition to the state management protocol specified in draft-ietf-http-state-man-mec-03[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.


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. Proposed Standard
"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. Proposed Standard
"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."

Related Work


Roy Fielding <fielding@ics.uci.edu>
Department of Information and Computer Science
University of California, Irvine, CA 92697-3425
Last modified: 03 Jan 1998