Hypertext Transfer Protocol (HTTP/1.1): Introduction

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 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. HTTP/1.1 Semantics and Payloads - Protocol elements such as methods, status codes, and payload-specific header fields. Also includes content negotiation mechanisms. HTTP/1.1 Conditional Requests - An extension to make requests contingent upon their current state. HTTP/1.1 Range Requests - An extension to request that only a portion of a response be sent back. HTTP/1.1 Caching - An extension to allow storage and reuse of responses. 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 . 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".

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 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. TODO: remove corresponding text from p1 Introduction.