HTTP/1.1, part 0: Introduction
draft-ietf-httpbis-p0-introduction-latest

Abstract

This document is the first in a series that, collectively, define the HyperText Transfer Protocol, version 1.1; otherwise known as HTTP/1.1.

Editorial Note (To be removed by RFC Editor)

Discussion of this draft takes place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived at <http://lists.w3.org/Archives/Public/ietf-http-wg/>.

The current issues list is at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related documents (including fancy diffs) can be found at <http://tools.ietf.org/wg/httpbis/>.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress”.

This Internet-Draft will expire on January 17, 2013.

Copyright Notice

Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents

• 1.   Introduction to the HTTP Document Series
• 2.   What is HTTP?
• 3.   References
  • 3.1   Normative References
  • 3.2   Informative References
• Authors' Addresses
• Index

1. Introduction to the HTTP Document Series

This document is the first in a series that, collectively, define the HyperText Transfer Protocol, version 1.1; otherwise known as HTTP/1.1.

The document series is organized as follows:

• HTTP/1.1 Introduction - this document
• [Part1] HTTP/1.1 Message Routing and Syntax - How to parse a HTTP/1.1 (or below) message, and layer it onto connection-oriented protocols. Also includes the HTTP and HTTPS URI schemes.
• [Part2] HTTP/1.1 Semantics and Payloads - Protocol elements such as methods, status codes, and payload-specific header fields. Also includes content negotiation mechanisms.
• [Part4] HTTP/1.1 Conditional Requests - An extension to make requests contingent upon their current state.
• [Part5] HTTP/1.1 Range Requests - An extension to request that only a portion of a response be sent back.
• [Part6] HTTP/1.1 Caching - An extension to allow storage and reuse of responses.
• [Part7] HTTP/1.1 Authentication Framework - extension enabling client authentication to proxy and origin servers

The "core" of HTTP/1.1 is defined by the first two specifications. The remaining specifications in the series are generally not mandatory for implementations, but might be required in some implementation or deployment scenarios; when this is the case, it will be noted.

Collectively, these documents obsolete [RFC2616]. Note that many other specifications extend and refine the use of HTTP (generally, as protocol extensions, where allowed by these specifications); they are not considered part of this series, but they are still "part of HTTP".

2. What is HTTP?

The Hypertext Transfer Protocol (HTTP) is an application-level request/response protocol that uses extensible semantics and MIME-like message payloads for flexible interaction with network-based hypertext information systems. HTTP relies upon the Uniform Resource Identifier (URI) standard [RFC3986] to indicate the target resource and relationships between resources.

HTTP is a generic interface protocol for information systems. It is designed to hide the details of how a service is implemented by presenting a uniform interface to clients that is independent of the types of resources provided. Likewise, servers do not need to be aware of each client's purpose: an HTTP request can be considered in isolation rather than being associated with a specific type of client or a predetermined sequence of application steps. The result is a protocol that can be used effectively in many different contexts and for which implementations can evolve independently over time.

HTTP is also designed for use as an intermediation protocol for translating communication to and from non-HTTP information systems. HTTP proxies and gateways can provide access to alternative information services by translating their diverse protocols into a hypertext format that can be viewed and manipulated by clients in the same way as HTTP services.

One consequence of HTTP flexibility is that the protocol cannot be defined in terms of what occurs behind the interface. Instead, we are limited to defining the syntax of communication, the intent of received communication, and the expected behavior of recipients. If the communication is considered in isolation, then successful actions ought to be reflected in corresponding changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.

[rfc.comment.1: TODO: remove corresponding text from p1 Introduction.]

3. References

3.1 Normative References

3.2 Informative References

Index

P R