IETF - Hypertext Transfer Protocol (HTTP) Working GroupIETFHypertext Transfer Protocol (HTTP) Working Group HTTP Working Group Charter Mailing List Archive and FindMail Archive Meeting Notes Specifications Requests for Comments (RFC) Primary HTTP Revision Drafts HTTP Extension Mechanisms Content Negotiation in HTTP Miscellaneous Drafts regarding HTTP Historical Documents Related Work (links to other sites) About the Internet Engineering Task Force IETF Applications Area and Document Actions Other IETF Working Groups Internet Notes at ISI Internet RFCs at Innosoft Mailing List and ArchivesDiscussion of these and related topics takes place on the HTTP workinggroup mailing list <http-wg@hplb.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@hplb.hpl.hp.com>.A hypertext archiveof the mailing list is available at UCI and also atFindMail.Meeting NotesHTTP Errata PageHTTP/1.1 Issues ListChicago 42nd IETFWashington D.C. 40th IETFMunich 39th IETFMemphis 38th IETFSan Jose 37th IETFMontreal 36th IETFLos Angeles 35th IETFDallas 34th IETFRoy's HTTP/1.x slidesfor Dallas IETF (Postscript)Stockholm 33rd IETFDanvers 32nd IETFSan Jose 31st IETF (BOF)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>AbstractRecently there has been widespread interest in using HypertextTransport Protocol (HTTP) as a substrate for other applications-levelprotocols. This document relates current IESG and IAB thinking ontechnical particulars of such use, including use of default ports, URLschemes, and HTTP security mechanisms. This thinking is subject tochange 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>AbstractThe mechanisms described in 'HTTP State Management Mechanism'[RFC-XXXX] and its predecessor [RFC-2109] can be used for manydifferent purposes. However, some current and potential usesof the protocol are controversial because they havesignificant user privacy and security implications. This memoidentifies specific uses of HTTP State Management protocolwhich are either (a) not recommended by the IETF, or (b)believed to be harmful, and discouraged. This memo alsodetails additional privacy considerations which are notcovered 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>AbstractThis document specifies a way to create a stateful session with HTTPrequests and responses. It describes two new headers, Cookie and Set-Cookie2, which carry state information between participating originservers and user agents. The method described here differs fromNetscape's Cookie proposal [Netscape], but it can interoperate withHTTP/1.0 user agents that use Netscape's method. (See the HISTORICALsection.)This document reflects implementation experience with RFC 2109 [RFC2109]and obsoletes it.HTTP Extension MechanismsApparently this is not a working group, but is being discussed on theHTTP-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>AbstractA number of other protocols may make use of HTTP syntaxand facilities; this memo defines a mechanism for IANA toallocate 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>AbstractAs 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 newfunctionality or to overload an existing one such as POST. Our belief isthat in most cases, overloading existing method names, with POST as aparticularly troublesome example, is a bad idea. We, as a group ofindividuals, suggest that the default requirement for new HTTP functionalitymust 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 NegotiationThis has now been assigned to the newContent 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>AbstractA number of Internet application protocols have a need to providecontent negotiation for the resources with which they interact. WhileMIME media types [1] provide a standard method for handling onemajor axis of variation, resources also vary in ways which cannot beexpressed using currently available MIME headers. This paper assertsthat a cross-protocol negotiation framework is needed, both toleverage work already done for specific protocols and to allow forcontent negotiation when resources will pass through severalprotocols on their way from provider to recipient. To justify theneed, this paper puts forward several content negotiation scenariosand 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>AbstractRecent 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 thisvocabulary, 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>AbstractIn RFC 2533,'A syntax for describing media feature sets', anexpression format is presented for describing media featurecapabilities using simple media feature tags.This memo contains two corrections to that specification: onefixes an error in the formal syntax specification, and the otherfixes an error in the rules for reducing feature comparisonpredicates. "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>AbstractThis 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 beenmotivated by WWW Consortium (W3C) work on CompositeCapability/Preference Profiles (CCPP) [5] that parallels someaspects of the IETF 'conneg' work.This is presented as a discussion document, with a view to maybeintegrating some of these ideas into ongoing 'conneg' work, and toindicate some areas for ongoing collaboration between the IETF andW3C 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>AbstractIn 'A syntax for describing media feature sets', an expressionformat is presented for describing media feature capabilities usingsimple media feature tags.This memo defines a MIME 'Content-features:' header that can beused 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>AbstractIn RFC 2533, 'A syntax for describing media feature sets', anexpression format is presented for describing media featurecapabilities using simple media feature tags.This memo defines a media feature tag whose value is a MIME contenttype. This allows the construction of feature expressions thattake 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>AbstractIn RFC 2533 [1], an expression format is presented for describingmedia feature capabilities as a combination of simple media featuretags [2].This document describes an abbreviated format for a composite mediafeature set, based upon a hash of the feature expression describingthat composite, or the URI of a resource containing the featureexpression. "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>AbstractRFC 2533,'A syntax for describing media feature sets', defines aformat to express media feature sets that represent media handlingcapabilities. It also describes an algorithm for matching thesefeature sets, which may be used, for example, to determine whetherthe 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>AbstractMany HTTP requests cause the retrieval of slightly modifiedinstances of resources for which the client already has acache entry. Research has shown that such modifyingupdates are frequent, and that the modifications aretypically much smaller than the actual entity. In suchcases, HTTP would make more efficient use of networkbandwidth if it could transfer a minimal description of thechanges, rather than the entire new instance of theresource. This is called 'delta encoding.' Thisdocument describes how delta encoding can be supported as acompatible 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>AbstractThis document specifies a way to create a stateful session, using HTTPrequests and responses, between an HTTP proxy server and its client. Itdescribes two new headers, Pcookie and Set-Pcookie, which carry stateinformation 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>AbstractThis 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>AbstractThis memo describes how to use TLS to secure HTTP connections overthe Internet. Current practice is to layer HTTP over SSL (the prede-cessor to TLS), distinguishing secured traffic from insecure trafficby the use of a different server port. This document documents thatpractice using TLS. A companion document describes a method for usingHTTP/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>AbstractThis 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>AbstractWIRE extends HTTP with a new type of redirect response that permits aresolver to explicitly delegate a resolution to other resolvers andprotocols. WIRE is an effort to make delegation more explicit, redirectionmore flexible, and resolution processes more efficient through the use ofhints. This document defines WIRE and describes the expected behaviors ofresolvers and clients using WIRE. WIRE is an extension of the HyperTextTransfer Protocol (HTTP), and is intended to be compatible with HTTP/1.0 andabove [4][5]. WIRE encourages use of long-lived URIs and at the same time supportsprotocol evolution without having to change currently deployed URIs or URIschemes. The extension is based on a simple URI resolution model that allowsan application to dynamically request metadata describing where and how toaccess a resource. The model can use any generic metadata descriptionlanguage (e.g. RDF) and as the metadata itself is interpreted as a firstclass resource, metadata resources are no different than any other resourceon 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>AbstractThis document specifies an addition to the state management protocolspecified in draft-ietf-http-state-man-mec-08[Kristol]. The intent isto provide a mechanism that allows user agents to determine the privacypractices of a server and to accept or reject cookies based on thosepractices. Allowing the user to establish preferences for how to handlecookies based on the server's practices provides a practical mechanismto provide users control over the privacy implications of cookies. To provide verification of server privacy practices, we assume theexistence of one or more independent Trust Authorities. The authorityestablishes PICS ratings representing server privacy practices. It thenissues trust-labels, in the form of digitally signed PICS labels, toorganizations for specific domains and paths based on the server privacypractices. The Trust Authority must be able to audit domains toverify their adherence to a given level. Passing these trust-labelsalong with cookies allows the user agent to support cookie handlingpreferences based on trusted privacy practices. This document describes how PICS-headers are used in conjunction withSet-Cookie or Set-Cookie2 headers in [Kristol] to provide trust-labelsto 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>AbstractThe HTTP 1.1 specification describes how a server can answer arequest with a redirection, instructing the client to get theresource from a different URL. It doesn't explain what to do with anyfragment identifier that might have been on the original URL, andthis omission has resulted in different clients handling fragments indifferent ways. This draft gives rules towards a more consistenthandling 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>AbstractMany Internet services need asynchronous notifications. At the sametime there is an increasing number of protocols which use HTTP orHTTP-alike request-response transactions.This document proposes an extension to application protocols whichenables asynchronous notifications from server to client throughclient initiated request-response transactions. The extension appliesthe 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>AbstractThis 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>AbstractThis 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>AbstractSOAP defines an RPC mechanism using XML for client-serverinteraction 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>AbstractWeb servers are becoming more complex, and as a result are losingthe full benefits of HTTP protocol compliance.This applicability statement defines classifications of Web serversub-components and clarifies their responsibilities in implementingHTTP/1.1 protocol features, with a discussion of the motivations fordoing so. "Geographic extensions for HTTP transactions", A. Daviel, 10 Sep 1999. Text version of <draft-daviel-http-geo-header-00.txt>AbstractThis memo describes a method of adding simple geographic positioninformation to HTTP transactions using extension headers. In thecase of an HTTP request, the extensions indicate a geographicposition or region that the requesting agent is interested in. Thisinformation may be used by a server to present appropriate position-dependant responses, such as search engine results, without theadditional overhead of geographic query requests. In the case of anHTTP response, the extensions indicate a geographic position orregion relevant to the resource described in the body of theresponse. This information may be used for automated resourcediscovery.Requests for CommentsRFC 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.AbstractThe Hypertext Transfer Protocol (HTTP) is an application-level protocol fordistributed, 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.AbstractThis document specifies a way to create a stateful session with HTTPrequests and responses. It describes two new headers, Cookie andSet-Cookie, which carry state information between participating originservers and user agents.RFC 2145. Informational"Use and Interpretation of HTTP Version Numbers", J. C. Mogul, R. Fielding, J. Gettys, H. Frystyk, May 1997.AbstractHTTP request and response messages include an HTTP protocol versionnumber. Some confusion exists concerning the proper use andinterpretation of HTTP version numbers, and concerninginteroperability of HTTP implementations of different protocolversions. 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.AbstractThis 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 originservers, in a more efficient manner than the "cache-busting"techniques currently used. It also permits an origin server tocontrol the number of times a cache uses a cached response, andoutlines a technique that origin servers can use to capture referralinformation 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.AbstractHTTP allows web site authors to put multiple versions of the sameinformation under a single URL. Transparent content negotiation is amechanism for automatically selecting the best version when the URL isaccessed. A remote variant selection algorithm can be used to speedup the transparent negotiation process. This document defines theremote 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>AbstractThis memo explains how to use the Upgrade mechanism in HTTP/1.1 toinitiate Transport Layer Security (TLS) over an existing TCPconnection. This allows unsecured and secured HTTP traffic to sharethe same well known port (in this case, http: at 80 rather thanhttps: at 443). It also enables 'virtual hosting,' so a single HTTP+ TLS server can disambiguate traffic intended for several hostnamesat a single IP address. Since HTTP/1.1[1] defines Upgrade as a hop-by-hop mechanism, thismemo also documents the HTTP CONNECT method for establishingend-to-end tunnels across HTTP proxies. Finally, this memoestablishes new IANA registries for public HTTP status codes, aswell as public or private Upgrade product tokens.Related WorkGeneral Discussion and ArchivesHTTP-WG Mailing List ArchivesW3C's Overview of HTTPHTTP Made Really Easy: a tutorial by James MarshallIllustrated Guide to HTTP by Paul S. HethmonSecurity and AuthenticationIETF Web Transaction Security (WTS) Working GroupW3C libwww implementation notesPerformanceSimon Spero's paper on HTTP performance problemsVenkata N. Padmanabhan and Jeffrey C. Mogul's work on Improving HTTP LatencyAnalysis of HTTP Performance by Joe Touch, John Heidemann, and Katia Obraczka (USC/ISI).Potential benefits of delta encoding and data compression for HTTP byJeffrey C. Mogul, Fred Douglis, Anja Feldmann, and Balachander Krishnamurthy.Management of HTTP Server Daemons and ContentHTTP MIB interest groupUCI WebSoft projectWWW Distributed Authoring and VersioningInternet Media TypesIANA Media Type RegistryHarald's notes on Media Types and the IETF Registration ProcessReturning Values from Forms: multipart/form-dataInternet MessagesSTD 10 (RFC 821) on SMTPSTD 11 (RFC 822) on Mail Messages (updated by RFC 1123)RFC 1036 on USENET news messagesRFC 1421 on Privacy Enhanced Mail (PEM)RFC 2076 on Common Internet Message Headers by J. PalmeMultipurpose Internet Mail Extensions (MIME) RFCsRFC 2045, MIME Part One: Format of Internet Message BodiesRFC 2046, MIME Part Two: Media TypesRFC 2047, MIME Part Three: Message Header Extensions for Non-ASCII TextRFC 2048, MIME Part Four: Registration ProceduresRFC 2049, MIME Part Five: Conformance Criteria and ExamplesRFC 2110, MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)RFC 2387, The MIME Multipart/Related Content-typeRelated Standards and DraftsInternet Assigned Numbers (STD 2) -- the IANA registryRFC 1766 (Language Tags)ISO 639 (Language Codes)ISO 3166 (Country Codes)The WWW Common Gateway Interface: Version 1.1Tunneling TCP based protocols through Web serversRelated Working GroupsIETF HTTP Extensions Working GroupIETF Web Distributed Authoring and Versioning (WEBDAV) Working GroupIETF Content Negotiation (conneg) Working Group.IETF HTML Working Group (concluded)IETF URI Working Group (concluded)IETF Web Transaction Security (WTS) Working Group (concluded)Roy FieldingDepartment of Information and Computer ScienceUniversity of California, Irvine, CA 92697-3425Last modified: 21 Feb 2000 |
|
