Web Technical Specifications -- HTTP

[Up] Web Documentation

On This page: Standards | Corporate | Proposals | See Also

Official Standards Documents

RFC 1945
HTTP 1.0 Specification (Informational)
Official Specification for Version 1.0 of the HyperText Transfer Protocol (HTTP). This specification reflects current practice as of the publication of the RFC (May 1996).

RFC 2068
HTTP 1.1 Specification (Proposed Standard)
Specifications for Version 1.1 of the HTTP protocol. This is approved by the Internet Engineering Steering Group (IESG), but has not yet been assigned an RFC number.

http://home.netscape.com/newsref/std/cookie_spec.html
Netscape Cookies -- Vendor-Defined "Standard"
The Netscape specification for cookies -- an HTTP mechanism for preserving state between HTTP transactions by storing "cookie" data on a client's hard disk. This mechanism is now widely supported, although it is likely to be soon replaced by the cookie mechanism described in the HTTP State Management Mechanism RFC mentioned below.

RFC xxxx
HTTP State Management Mechanism (Proposed Standard)
Defines a new standard for maintaining state on a server using a cookie exchange mechanism as part of HTTP request and response headers. This mechanism is different from the Netscape Cookie mechanism, but can coexist with this earlier protocol. This document has been approved by the IESG, but has not yet been assigned an RFC number.

RFC 2069
An Extension to HTTP: Digest Access Authentication (Proposed Standard)
A proposed extension to HTTP 1.0 that provides a user authentication/access control protocol substantially improved upon the "Basic" authentication supported by HTTP/1.0. Digest authentication supports encryption of the transmitted username and password. This document has been approved by the IESG, but has not yet been assigned an RFC number.

RFC 2048
Media Type Registration Procedure (Informational)
Specification for the mechanism for registering MIME Internet Media type. If you want to introduce a new media type for Internet use (as email or as an HTTP data message), this is the way you indicate the name of this type to the rest of the world.

Corporate Specifications

No relevant standards -- the specificaiton of the HTTP protocol has largely been left in the hands of the IETF working groups and the W3C.

Standards Proposals

http://www.w3.org/pub/WWW/TR/WD-http-pep.html (also draft-ietf-http-pep-01.html)
HTTP/1.2 Extension Protocol (PEP)
PEP is a system for HTTP clients, servers, and proxies to reliably reason about custom extensions to HTTP.

draft-holtman-http-negotiation-04.txt
Transparent Content Negotiation in HTTP
Transparent content negotiation is a 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.

draft-holtman-http-safe-01.txt
The Safe Response Header
This document proposes a HTTP response header called Safe, which can be used to label the corresponding POST request as being safe. This labeling will allow user agents to present services which use safe POSTs in a more user-friendly way. Improving the user-friendliness of safe POSTs is considered important, because web internationalization will depend for a large part on the use of safe POSTs.

draft-mutz-http-attributes-02.txt
User-Agent Display Attributes
User-Agent Display Attributes Headers provide a means for an HTTP client and server to negotiate for content dependent on the client display capabilities. This memo describes feature tags for introducing this information into an HTTP transmission.

draft-mogul-http-hit-metering-00.txt
Simple Hit-Metering for HTTP
This draft proposes a simple extension to HTTP, using a new "Meter" header, to permit demographic information to be reported by caches to origin servers, and to permit an origin server to control the number of times a cache uses a cached response. It also outlines techniques that origin servers can use to capture referral information without "cache-busting.

draft-whitehead-http-distreq-00.txt
Requirements on HTTP for Distributed Content Editing
This document presents a list of features in the form of requirements which, if implemented, would improve the efficiency of common remote editing operations, provide a locking mechanism to prevent overwrite conflicts, improve relationship management support between non-HTML data types, provide a simple attribute-value metadata facility, and provide for the creation and reading of container data types. (background information on distributed authoring).

draft-ota-http-version-00.txt
Version management with meta-level links via HTTP/1.1
This document describes a mechanism for version management of resources, which uses meta-level links. A meta-level link relates two resources outside the contents of resources. So, the contents need not to be an HTML format. This document also describes the classification of the PUT method. It is used for the server to distinguish between normal resources and versioned resources.

draft-petke-http-auth-scheme-00.txt
Remote Passphrase Authentication - HTTP Authentication Scheme
Remote Passphrase Authentication provides a way to authenticate a user to a service by using a pass phrase over an insecure network, without revealing the pass phrase to eavesdroppers. There are three additional ID documents related to this proposal.

draft-pritchard-http-links-00.txt
Efficient HyperLink Maintenance for HTTP
Hyperlink maintenance allows robots and servers to cooperate in propagating the effects of daily changes in the millions of resource locations in the wwweb. Here, we propose developing the definitions of the LINK and UNLINK methods defined for HTTP since RFC 1945 and which remain largely unimplemented and unused.

http://www.w3.org/pub/WWW/Protocols/HTTP-NG/Overview.html
HTTP-NG -- Next Generation HTTP
The current version of HTTP is restricted by the need to use MIME to encapsulate the data, plus some limitations in the form of the transport mechanism itself. This site (and the referenced documentation) describes ideas for a next-generation of HTTP (HTTP/2.0?) that would overcome some of these limitations.