You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@labs.apache.org by fi...@apache.org on 2007/10/09 02:35:38 UTC
svn commit: r583020 [4/8] - in /labs/webarch/trunk/http/draft-fielding-http:
p1-messaging.xml p2-semantics.xml p3-payload.xml p4-conditional.xml
p5-range.xml p6-cache.xml p7-auth.xml
Modified: labs/webarch/trunk/http/draft-fielding-http/p3-payload.xml
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p3-payload.xml?rev=583020&r1=583019&r2=583020&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p3-payload.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p3-payload.xml Mon Oct 8 17:35:37 2007
@@ -1,4 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
+<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc [
<!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>">
@@ -11,6 +11,17 @@
<!ENTITY SHALL-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL NOT</bcp14>">
<!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>">
<!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>">
+ <!ENTITY caching "[Part 6]">
+ <!ENTITY header-transfer-encoding "[Part 1]">
+ <!ENTITY header-allow "[Part 2]">
+ <!ENTITY header-content-length "[Part 1]">
+ <!ENTITY header-content-range "[Part 5]">
+ <!ENTITY header-expires "[Part 6]">
+ <!ENTITY header-last-modified "[Part 4]">
+ <!ENTITY header-user-agent "[Part 2]">
+ <!ENTITY message-body "[Part 1]">
+ <!ENTITY message-length "[Part 1]">
+ <!ENTITY multipart-byteranges "[Part 5]">
]>
<?rfc toc="yes" ?>
<?rfc symrefs="no" ?>
@@ -20,11 +31,12 @@
<?rfc editing="no" ?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext include-references-in-index="yes" ?>
-<rfc number="2616" category="std" obsoletes="2068" xmlns:x='http://purl.org/net/xml2rfc/ext' xmlns:ed="http://greenbytes.de/2002/rfcedit" >
-<x:assign-section-number number="18" builtin-target="authors"/>
+<rfc obsoletes="2068, 2616, 2617" category="std"
+ ipr="full3667" docName="draft-fielding-http-p3-payload-00"
+ xmlns:x='http://purl.org/net/xml2rfc/ext' xmlns:ed="http://greenbytes.de/2002/rfcedit">
<front>
- <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
+ <title abbrev="HTTP/1.1">HTTP/1.1, part 3: Payload</title>
<author initials="R." surname="Fielding" fullname="Roy T. Fielding">
<organization abbrev="UC Irvine">Department of Information and Computer Science</organization>
@@ -126,8770 +138,1174 @@
</address>
</author>
- <date month="June" year="1999"/>
+ <date month="September" year="2007"/>
<abstract>
<t>
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 <xref target="RFC2324"/>. A feature of HTTP is
- the typing and negotiation of data representation, allowing systems
- to be built independently of the data being transferred.
-</t>
-<t>
- 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 <xref target="RFC2068"/>.
+ systems. HTTP has been in use by the World Wide Web global information
+ initiative since 1990. This document is Part 3 of the eight-part specification
+ that defines the protocol referred to as "HTTP/1.1" and, taken together,
+ updates RFC 2616 and RFC 2617. Part 3 defines HTTP message content,
+ metadata, and content negotiation.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
-
-<section title="Purpose">
-<t>
- The Hypertext Transfer Protocol (HTTP) is an application-level
- protocol for distributed, collaborative, hypermedia information
- systems. HTTP has been in use by the World-Wide Web global
- information initiative since 1990. The first version of HTTP,
- referred to as HTTP/0.9, was a simple protocol for raw data transfer
- across the Internet. HTTP/1.0, as defined by RFC 1945 <xref target="RFC1945"/>, improved
- the protocol by allowing messages to be in the format of MIME-like
- messages, containing metainformation about the data transferred and
- modifiers on the request/response semantics. However, HTTP/1.0 does
- not sufficiently take into consideration the effects of hierarchical
- proxies, caching, the need for persistent connections, or virtual
- hosts. In addition, the proliferation of incompletely-implemented
- applications calling themselves "HTTP/1.0" has necessitated a
- protocol version change in order for two communicating applications
- to determine each other's true capabilities.
-</t>
-<t>
- This specification defines the protocol referred to as "HTTP/1.1".
- This protocol includes more stringent requirements than HTTP/1.0 in
- order to ensure reliable implementation of its features.
-</t>
-<t>
- Practical information systems require more functionality than simple
- retrieval, including search, front-end update, and annotation. HTTP
- allows an open-ended set of methods and headers that indicate the
- purpose of a request <xref target="RFC2324"/>. It builds on the discipline of reference
- provided by the Uniform Resource Identifier (URI) <xref target="RFC1630"/>, as a location
- (URL) <xref target="RFC1738"/> or name (URN) <xref target="RFC1737"/>, for indicating the resource to which a
- method is to be applied. Messages are passed in a format similar to
- that used by Internet mail <xref target="RFC822"/> as defined by the Multipurpose
- Internet Mail Extensions (MIME) <xref target="RFC2045"/>.
-</t>
<t>
- HTTP is also used as a generic protocol for communication between
- user agents and proxies/gateways to other Internet systems, including
- those supported by the SMTP <xref target="RFC821"/>, NNTP <xref target="RFC977"/>, FTP <xref target="RFC959"/>, Gopher <xref target="RFC1436"/>,
- and WAIS <xref target="WAIS"/> protocols. In this way, HTTP allows basic hypermedia
- access to resources available from diverse applications.
+ This document will define aspects of HTTP related to the payload of
+ messages (message content), including metadata and media types, along
+ with HTTP content negotiation. Right now it only includes the extracted
+ relevant sections of RFC 2616 without edit.
</t>
</section>
-<section title="Requirements">
-<t>
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 <xref target="RFC2119"/>.
-</t>
-<t>
- An implementation is not compliant if it fails to satisfy one or more
- of the &MUST; or &REQUIRED; level requirements for the protocols it
- implements. An implementation that satisfies all the &MUST; or &REQUIRED;
- level and all the &SHOULD; level requirements for its protocols is said
- to be "unconditionally compliant"; one that satisfies all the &MUST;
- level requirements but not all the &SHOULD; level requirements for its
- protocols is said to be "conditionally compliant."
-</t>
-</section>
+<section title="Protocol Parameters">
-<section title="Terminology">
-<t>
- This specification uses a number of terms to refer to the roles
- played by participants in, and objects of, the HTTP communication.
-</t>
-<t>
- <iref item="connection"/>
- <x:dfn>connection</x:dfn>
- <list>
- <t>
- A transport layer virtual circuit established between two programs
- for the purpose of communication.
- </t>
- </list>
-</t>
-<t>
- <iref item="message"/>
- <x:dfn>message</x:dfn>
- <list>
- <t>
- The basic unit of HTTP communication, consisting of a structured
- sequence of octets matching the syntax defined in <xref target="httpmessage"/> and
- transmitted via the connection.
- </t>
- </list>
-</t>
+<section title="Character Sets" anchor="character.sets">
<t>
- <iref item="request"/>
- <x:dfn>request</x:dfn>
- <list>
- <t>
- An HTTP request message, as defined in <xref target="request"/>.
- </t>
- </list>
+ HTTP uses the same definition of the term "character set" as that
+ described for MIME:
</t>
<t>
- <iref item="response"/>
- <x:dfn>response</x:dfn>
- <list>
- <t>
- An HTTP response message, as defined in <xref target="response"/>.
- </t>
- </list>
+ The term "character set" is used in this document to refer to a
+ method used with one or more tables to convert a sequence of octets
+ into a sequence of characters. Note that unconditional conversion in
+ the other direction is not required, in that not all characters may
+ be available in a given character set and a character set may provide
+ more than one sequence of octets to represent a particular character.
+ This definition is intended to allow various kinds of character
+ encoding, from simple single-table mappings such as US-ASCII to
+ complex table switching methods such as those that use ISO-2022's
+ techniques. However, the definition associated with a MIME character
+ set name &MUST; fully specify the mapping to be performed from octets
+ to characters. In particular, use of external profiling information
+ to determine the exact mapping is not permitted.
</t>
+<t><list><t>
+ <x:h>Note:</x:h> This use of the term "character set" is more commonly
+ referred to as a "character encoding." However, since HTTP and
+ MIME share the same registry, it is important that the terminology
+ also be shared.
+</t></list></t>
<t>
- <iref item="resource"/>
- <x:dfn>resource</x:dfn>
- <list>
- <t>
- A network data object or service that can be identified by a URI,
- as defined in <xref target="uri"/>. Resources may be available in multiple
- representations (e.g. multiple languages, data formats, size, and
- resolutions) or vary in other ways.
- </t>
- </list>
+ HTTP character sets are identified by case-insensitive tokens. The
+ complete set of tokens is defined by the IANA Character Set registry
+ <xref target="RFC1700"/>.
</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="charset"/>
+ charset = token
+</artwork></figure>
<t>
- <iref item="entity"/>
- <x:dfn>entity</x:dfn>
- <list>
- <t>
- The information transferred as the payload of a request or
- response. An entity consists of metainformation in the form of
- entity-header fields and content in the form of an entity-body, as
- described in <xref target="entity"/>.
- </t>
- </list>
+ Although HTTP allows an arbitrary token to be used as a charset
+ value, any token that has a predefined value within the IANA
+ Character Set registry <xref target="RFC1700"/> &MUST; represent the character set defined
+ by that registry. Applications &SHOULD; limit their use of character
+ sets to those defined by the IANA registry.
</t>
<t>
- <iref item="representation"/>
- <x:dfn>representation</x:dfn>
- <list>
- <t>
- An entity included with a response that is subject to content
- negotiation, as described in <xref target="content.negotiation"/>. There may exist multiple
- representations associated with a particular response status.
- </t>
- </list>
+ Implementors should be aware of IETF character set requirements <xref target="RFC2279"/>
+ <xref target="RFC2277"/>.
</t>
+
+<section title="Missing Charset" anchor="missing.charset">
<t>
- <iref item="content negotiation"/>
- <x:dfn>content negotiation</x:dfn>
- <list>
- <t>
- The mechanism for selecting the appropriate representation when
- servicing a request, as described in <xref target="content.negotiation"/>. The
- representation of entities in any response can be negotiated
- (including error responses).
- </t>
- </list>
+ Some HTTP/1.0 software has interpreted a Content-Type header without
+ charset parameter incorrectly to mean "recipient should guess."
+ Senders wishing to defeat this behavior &MAY; include a charset
+ parameter even when the charset is ISO-8859-1 and &SHOULD; do so when
+ it is known that it will not confuse the recipient.
</t>
<t>
- <iref item="variant"/>
- <x:dfn>variant</x:dfn>
- <list>
- <t>
- A resource may have one, or more than one, representation(s)
- associated with it at any given instant. Each of these
- representations is termed a `varriant'. Use of the term `variant'
- does not necessarily imply that the resource is subject to content
- negotiation.
- </t>
- </list>
+ Unfortunately, some older HTTP/1.0 clients did not deal properly with
+ an explicit charset parameter. HTTP/1.1 recipients &MUST; respect the
+ charset label provided by the sender; and those user agents that have
+ a provision to "guess" a charset &MUST; use the charset from the
+ content-type field if they support that charset, rather than the
+ recipient's preference, when initially displaying a document. See
+ <xref target="canonicalization.and.text.defaults"/>.
</t>
+</section>
+</section>
+
+<section title="Content Codings" anchor="content.codings">
<t>
- <iref item="client"/>
- <x:dfn>client</x:dfn>
- <list>
- <t>
- A program that establishes connections for the purpose of sending
- requests.
- </t>
- </list>
+ Content coding values indicate an encoding transformation that has
+ been or can be applied to an entity. Content codings are primarily
+ used to allow a document to be compressed or otherwise usefully
+ transformed without losing the identity of its underlying media type
+ and without loss of information. Frequently, the entity is stored in
+ coded form, transmitted directly, and only decoded by the recipient.
</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="content-coding"/>
+ content-coding = token
+</artwork></figure>
<t>
- <iref item="user agent"/>
- <x:dfn>user agent</x:dfn>
- <list>
- <t>
- The client which initiates a request. These are often browsers,
- editors, spiders (web-traversing robots), or other end user tools.
- </t>
- </list>
+ All content-coding values are case-insensitive. HTTP/1.1 uses
+ content-coding values in the Accept-Encoding (<xref target="header.accept-encoding"/>) and
+ Content-Encoding (<xref target="header.content-encoding"/>) header fields. Although the value
+ describes the content-coding, what is more important is that it
+ indicates what decoding mechanism will be required to remove the
+ encoding.
</t>
<t>
- <iref item="server"/>
- <x:dfn>server</x:dfn>
- <list>
- <t>
- An application program that accepts connections in order to
- service requests by sending back responses. Any given program may
- be capable of being both a client and a server; our use of these
- terms refers only to the role being performed by the program for a
- particular connection, rather than to the program's capabilities
- in general. Likewise, any server may act as an origin server,
- proxy, gateway, or tunnel, switching behavior based on the nature
- of each request.
- </t>
- </list>
+ The Internet Assigned Numbers Authority (IANA) acts as a registry for
+ content-coding value tokens. Initially, the registry contains the
+ following tokens:
</t>
<t>
- <iref item="origin server"/>
- <x:dfn>origin server</x:dfn>
+ gzip<iref item="gzip"/>
<list>
<t>
- The server on which a given resource resides or is to be created.
+ An encoding format produced by the file compression program
+ "gzip" (GNU zip) as described in RFC 1952 <xref target="RFC1952"/>. This format is a
+ Lempel-Ziv coding (LZ77) with a 32 bit CRC.
</t>
</list>
</t>
<t>
- <iref item="proxy"/>
- <x:dfn>proxy</x:dfn>
- <list>
- <t>
- An intermediary program which acts as both a server and a client
- for the purpose of making requests on behalf of other clients.
- Requests are serviced internally or by passing them on, with
- possible translation, to other servers. A proxy &MUST; implement
- both the client and server requirements of this specification. A
- "transparent proxy" is a proxy that does not modify the request or
- response beyond what is required for proxy authentication and
- identification. A "non-transparent proxy" is a proxy that modifies
- the request or response in order to provide some added service to
- the user agent, such as group annotation services, media type
- transformation, protocol reduction, or anonymity filtering. Except
- where either transparent or non-transparent behavior is explicitly
- stated, the HTTP proxy requirements apply to both types of
- proxies.
- </t>
- </list>
+ compress<iref item="compress"/>
+ <list><t>
+ The encoding format produced by the common UNIX file compression
+ program "compress". This format is an adaptive Lempel-Ziv-Welch
+ coding (LZW).
+</t><t>
+ Use of program names for the identification of encoding formats
+ is not desirable and is discouraged for future encodings. Their
+ use here is representative of historical practice, not good
+ design. For compatibility with previous implementations of HTTP,
+ applications &SHOULD; consider "x-gzip" and "x-compress" to be
+ equivalent to "gzip" and "compress" respectively.
+ </t></list>
</t>
<t>
- <iref item="gateway"/>
- <x:dfn>gateway</x:dfn>
- <list>
- <t>
- A server which acts as an intermediary for some other server.
- Unlike a proxy, a gateway receives requests as if it were the
- origin server for the requested resource; the requesting client
- may not be aware that it is communicating with a gateway.
- </t>
- </list>
+ deflate<iref item="deflate"/>
+ <list><t>
+ The "zlib" format defined in RFC 1950 <xref target="RFC1950"/> in combination with
+ the "deflate" compression mechanism described in RFC 1951 <xref target="RFC1951"/>.
+ </t></list>
</t>
<t>
- <iref item="tunnel"/>
- <x:dfn>tunnel</x:dfn>
- <list>
- <t>
- An intermediary program which is acting as a blind relay between
- two connections. Once active, a tunnel is not considered a party
- to the HTTP communication, though the tunnel may have been
- initiated by an HTTP request. The tunnel ceases to exist when both
- ends of the relayed connections are closed.
- </t>
- </list>
+ identity<iref item="identity"/>
+ <list><t>
+ The default (identity) encoding; the use of no transformation
+ whatsoever. This content-coding is used only in the Accept-Encoding
+ header, and &SHOULD-NOT; be used in the Content-Encoding
+ header.
+ </t></list>
</t>
<t>
- <iref item="cache"/>
- <x:dfn>cache</x:dfn>
- <list>
- <t>
- A program's local store of response messages and the subsystem
- that controls its message storage, retrieval, and deletion. A
- cache stores cacheable responses in order to reduce the response
- time and network bandwidth consumption on future, equivalent
- requests. Any client or server may include a cache, though a cache
- cannot be used by a server that is acting as a tunnel.
- </t>
- </list>
+ New content-coding value tokens &SHOULD; be registered; to allow
+ interoperability between clients and servers, specifications of the
+ content coding algorithms needed to implement a new value &SHOULD; be
+ publicly available and adequate for independent implementation, and
+ conform to the purpose of content coding defined in this section.
</t>
+</section>
+
+<section title="Media Types" anchor="media.types">
<t>
- <iref item="cacheable"/>
- <x:dfn>cacheable</x:dfn>
- <list>
- <t>
- A response is cacheable if a cache is allowed to store a copy of
- the response message for use in answering subsequent requests. The
- rules for determining the cacheability of HTTP responses are
- defined in <xref target="caching"/>. Even if a resource is cacheable, there may
- be additional constraints on whether a cache can use the cached
- copy for a particular request.
- </t>
- </list>
+ HTTP uses Internet Media Types <xref target="RFC1590"/> in the Content-Type (<xref target="header.content-type"/>)
+ and Accept (<xref target="header.accept"/>) header fields in order to provide
+ open and extensible data typing and type negotiation.
</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="media-type"/><iref primary="true" item="Grammar" subitem="type"/><iref primary="true" item="Grammar" subitem="subtype"/>
+ media-type = type "/" subtype *( ";" parameter )
+ type = token
+ subtype = token
+</artwork></figure>
<t>
- <iref item="first-hand"/>
- <x:dfn>first-hand</x:dfn>
- <list>
- <t>
- A response is first-hand if it comes directly and without
- unnecessary delay from the origin server, perhaps via one or more
- proxies. A response is also first-hand if its validity has just
- been checked directly with the origin server.
- </t>
- </list>
+ Parameters &MAY; follow the type/subtype in the form of attribute/value
+ pairs.
</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="parameter"/><iref primary="true" item="Grammar" subitem="attribute"/><iref primary="true" item="Grammar" subitem="value"/>
+ parameter = attribute "=" value
+ attribute = token
+ value = token | quoted-string
+</artwork></figure>
<t>
- <iref item="explicit expiration time"/>
- <x:dfn>explicit expiration time</x:dfn>
- <list>
- <t>
- The time at which the origin server intends that an entity should
- no longer be returned by a cache without further validation.
- </t>
- </list>
+ The type, subtype, and parameter attribute names are case-insensitive.
+ Parameter values might or might not be case-sensitive,
+ depending on the semantics of the parameter name. Linear white space
+ (LWS) &MUST-NOT; be used between the type and subtype, nor between an
+ attribute and its value. The presence or absence of a parameter might
+ be significant to the processing of a media-type, depending on its
+ definition within the media type registry.
</t>
<t>
- <iref item="heuristic expiration time"/>
- <x:dfn>heuristic expiration time</x:dfn>
- <list>
- <t>
- An expiration time assigned by a cache when no explicit expiration
- time is available.
- </t>
- </list>
+ Note that some older HTTP applications do not recognize media type
+ parameters. When sending data to older HTTP applications,
+ implementations &SHOULD; only use media type parameters when they are
+ required by that type/subtype definition.
</t>
<t>
- <iref item="age"/>
- <x:dfn>age</x:dfn>
- <list>
- <t>
- The age of a response is the time since it was sent by, or
- successfully validated with, the origin server.
- </t>
- </list>
+ Media-type values are registered with the Internet Assigned Number
+ Authority (IANA <xref target="RFC1700"/>). The media type registration process is
+ outlined in RFC 1590 <xref target="RFC1590"/>. Use of non-registered media types is
+ discouraged.
</t>
+
+<section title="Canonicalization and Text Defaults" anchor="canonicalization.and.text.defaults">
<t>
- <iref item="freshness lifetime"/>
- <x:dfn>freshness lifetime</x:dfn>
- <list>
- <t>
- The length of time between the generation of a response and its
- expiration time.
- </t>
- </list>
+ Internet media types are registered with a canonical form. An
+ entity-body transferred via HTTP messages &MUST; be represented in the
+ appropriate canonical form prior to its transmission except for
+ "text" types, as defined in the next paragraph.
</t>
<t>
- <iref item="fresh"/>
- <x:dfn>fresh</x:dfn>
- <list>
- <t>
- A response is fresh if its age has not yet exceeded its freshness
- lifetime.
- </t>
- </list>
-</t>
-<t>
- <iref item="stale"/>
- <x:dfn>stale</x:dfn>
- <list>
- <t>
- A response is stale if its age has passed its freshness lifetime.
- </t>
- </list>
-</t>
-<t>
- <iref item="semantically transparent"/>
- <x:dfn>semantically transparent</x:dfn>
- <list>
- <t>
- A cache behaves in a "semantically transparent" manner, with
- respect to a particular response, when its use affects neither the
- requesting client nor the origin server, except to improve
- performance. When a cache is semantically transparent, the client
- receives exactly the same response (except for hop-by-hop headers)
- that it would have received had its request been handled directly
- by the origin server.
- </t>
- </list>
-</t>
-<t>
- <iref item="validator"/>
- <x:dfn>validator</x:dfn>
- <list>
- <t>
- A protocol element (e.g., an entity tag or a Last-Modified time)
- that is used to find out whether a cache entry is an equivalent
- copy of an entity.
- </t>
- </list>
-</t>
-<t>
- <iref item="upstream"/>
- <iref item="downstream"/>
- <x:dfn>upstream</x:dfn>/<x:dfn>downstream</x:dfn>
- <list>
- <t>
- Upstream and downstream describe the flow of a message: all
- messages flow from upstream to downstream.
- </t>
- </list>
-</t>
-<t>
- <iref item="inbound"/>
- <iref item="outbound"/>
- <x:dfn>inbound</x:dfn>/<x:dfn>outbound</x:dfn>
- <list>
- <t>
- Inbound and outbound refer to the request and response paths for
- messages: "inbound" means "traveling toward the origin server",
- and "outbound" means "traveling toward the user agent"
- </t>
- </list>
-</t>
-</section>
-
-<section title="Overall Operation">
-<t>
- The HTTP protocol is a request/response protocol. A client sends a
- request to the server in the form of a request method, URI, and
- protocol version, followed by a MIME-like message containing request
- modifiers, client information, and possible body content over a
- connection with a server. The server responds with a status line,
- including the message's protocol version and a success or error code,
- followed by a MIME-like message containing server information, entity
- metainformation, and possible entity-body content. The relationship
- between HTTP and MIME is described in <xref target="differences.between.http.entities.and.rfc.2045.entities"/>.
-</t>
-<t>
- Most HTTP communication is initiated by a user agent and consists of
- a request to be applied to a resource on some origin server. In the
- simplest case, this may be accomplished via a single connection (v)
- between the user agent (UA) and the origin server (O).
-</t>
-<figure><artwork type="drawing">
- request chain ------------------------>
- UA -------------------v------------------- O
- <----------------------- response chain
-</artwork></figure>
-<t>
- A more complicated situation occurs when one or more intermediaries
- are present in the request/response chain. There are three common
- forms of intermediary: proxy, gateway, and tunnel. A proxy is a
- forwarding agent, receiving requests for a URI in its absolute form,
- rewriting all or part of the message, and forwarding the reformatted
- request toward the server identified by the URI. A gateway is a
- receiving agent, acting as a layer above some other server(s) and, if
- necessary, translating the requests to the underlying server's
- protocol. A tunnel acts as a relay point between two connections
- without changing the messages; tunnels are used when the
- communication needs to pass through an intermediary (such as a
- firewall) even when the intermediary cannot understand the contents
- of the messages.
-</t>
-<figure><artwork type="drawing">
- request chain -------------------------------------->
- UA -----v----- A -----v----- B -----v----- C -----v----- O
- <------------------------------------- response chain
-</artwork></figure>
-<t>
- The figure above shows three intermediaries (A, B, and C) between the
- user agent and origin server. A request or response message that
- travels the whole chain will pass through four separate connections.
- This distinction is important because some HTTP communication options
- may apply only to the connection with the nearest, non-tunnel
- neighbor, only to the end-points of the chain, or to all connections
- along the chain. Although the diagram is linear, each participant may
- be engaged in multiple, simultaneous communications. For example, B
- may be receiving requests from many clients other than A, and/or
- forwarding requests to servers other than C, at the same time that it
- is handling A's request.
-</t>
-<t>
- Any party to the communication which is not acting as a tunnel may
- employ an internal cache for handling requests. The effect of a cache
- is that the request/response chain is shortened if one of the
- participants along the chain has a cached response applicable to that
- request. The following illustrates the resulting chain if B has a
- cached copy of an earlier response from O (via C) for a request which
- has not been cached by UA or A.
-</t>
-<figure><artwork type="drawing">
- request chain ---------->
- UA -----v----- A -----v----- B - - - - - - C - - - - - - O
- <--------- response chain
-</artwork></figure>
-<t>
- Not all responses are usefully cacheable, and some requests may
- contain modifiers which place special requirements on cache behavior.
- HTTP requirements for cache behavior and cacheable responses are
- defined in <xref target="caching"/>.
-</t>
-<t>
- In fact, there are a wide variety of architectures and configurations
- of caches and proxies currently being experimented with or deployed
- across the World Wide Web. These systems include national hierarchies
- of proxy caches to save transoceanic bandwidth, systems that
- broadcast or multicast cache entries, organizations that distribute
- subsets of cached data via CD-ROM, and so on. HTTP systems are used
- in corporate intranets over high-bandwidth links, and for access via
- PDAs with low-power radio links and intermittent connectivity. The
- goal of HTTP/1.1 is to support the wide diversity of configurations
- already deployed while introducing protocol constructs that meet the
- needs of those who build web applications that require high
- reliability and, failing that, at least reliable indications of
- failure.
-</t>
-<t>
- HTTP communication usually takes place over TCP/IP connections. The
- default port is TCP 80 <xref target="RFC1700"/>, but other ports can be used. This does
- not preclude HTTP from being implemented on top of any other protocol
- on the Internet, or on other networks. HTTP only presumes a reliable
- transport; any protocol that provides such guarantees can be used;
- the mapping of the HTTP/1.1 request and response structures onto the
- transport data units of the protocol in question is outside the scope
- of this specification.
-</t>
-<t>
- In HTTP/1.0, most implementations used a new connection for each
- request/response exchange. In HTTP/1.1, a connection may be used for
- one or more request/response exchanges, although connections may be
- closed for a variety of reasons (see <xref target="persistent.connections"/>).
-</t>
-</section>
-</section>
-
-<section title="Notational Conventions and Generic Grammar">
-
-<section title="Augmented BNF">
-<t>
- All of the mechanisms specified in this document are described in
- both prose and an augmented Backus-Naur Form (BNF) similar to that
- used by RFC 822 <xref target="RFC822"/>. Implementors will need to be familiar with the
- notation in order to understand this specification. The augmented BNF
- includes the following constructs:
-</t>
-<t>
- name = definition
- <list>
- <t>
- The name of a rule is simply the name itself (without any
- enclosing "<" and ">") and is separated from its definition by the
- equal "=" character. White space is only significant in that
- indentation of continuation lines is used to indicate a rule
- definition that spans more than one line. Certain basic rules are
- in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle
- brackets are used within definitions whenever their presence will
- facilitate discerning the use of rule names.
- </t>
- </list>
-</t>
-<t>
- "literal"
- <list>
- <t>
- Quotation marks surround literal text. Unless stated otherwise,
- the text is case-insensitive.
- </t>
- </list>
-</t>
-<t>
- rule1 | rule2
- <list>
- <t>
- Elements separated by a bar ("|") are alternatives, e.g., "yes |
- no" will accept yes or no.
- </t>
- </list>
-</t>
-<t>
- (rule1 rule2)
- <list>
- <t>
- Elements enclosed in parentheses are treated as a single element.
- Thus, "(elem (foo | bar) elem)" allows the token sequences "elem
- foo elem" and "elem bar elem".
- </t>
- </list>
-</t>
-<t>
- *rule
- <list>
- <t>
- The character "*" preceding an element indicates repetition. The
- full form is "<n>*<m>element" indicating at least <n> and at most
- <m> occurrences of element. Default values are 0 and infinity so
- that "*(element)" allows any number, including zero; "1*element"
- requires at least one; and "1*2element" allows one or two.
- </t>
- </list>
-</t>
-<t>
- [rule]
- <list>
- <t>
- Square brackets enclose optional elements; "[foo bar]" is
- equivalent to "*1(foo bar)".
- </t>
- </list>
-</t>
-<t>
- N rule
- <list>
- <t>
- Specific repetition: "<n>(element)" is equivalent to
- "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
- Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
- alphabetic characters.
- </t>
- </list>
-</t>
-<t>
- #rule
- <list>
- <t>
- A construct "#" is defined, similar to "*", for defining lists of
- elements. The full form is "<n>#<m>element" indicating at least
- <n> and at most <m> elements, each separated by one or more commas
- (",") and &OPTIONAL; linear white space (LWS). This makes the usual
- form of lists very easy; a rule such as
- </t>
- <t>
- ( *LWS element *( *LWS "," *LWS element ))
- </t>
- <t>
- can be shown as
- </t>
- <t>
- 1#element
- </t>
- <t>
- Wherever this construct is used, null elements are allowed, but do
- not contribute to the count of elements present. That is,
- "(element), , (element) " is permitted, but counts as only two
- elements. Therefore, where at least one element is required, at
- least one non-null element &MUST; be present. Default values are 0
- and infinity so that "#element" allows any number, including zero;
- "1#element" requires at least one; and "1#2element" allows one or
- two.
- </t>
- </list>
-</t>
-<t>
- ; comment
- <list>
- <t>
- A semi-colon, set off some distance to the right of rule text,
- starts a comment that continues to the end of line. This is a
- simple way of including useful notes in parallel with the
- specifications.
- </t>
- </list>
-</t>
-<t>
- implied *LWS
- <list>
- <t>
- The grammar described by this specification is word-based. Except
- where noted otherwise, linear white space (LWS) can be included
- between any two adjacent words (token or quoted-string), and
- between adjacent words and separators, without changing the
- interpretation of a field. At least one delimiter (LWS and/or
- separators) &MUST; exist between any two tokens (for the definition
- of "token" below), since they would otherwise be interpreted as a
- single token.
- </t>
- </list>
-</t>
-</section>
-
-<section title="Basic Rules" anchor="basic.rules">
-<x:anchor-alias value="OCTET"/>
-<x:anchor-alias value="CHAR"/>
-<x:anchor-alias value="UPALPHA"/>
-<x:anchor-alias value="LOALPHA"/>
-<x:anchor-alias value="ALPHA"/>
-<x:anchor-alias value="DIGIT"/>
-<x:anchor-alias value="CTL"/>
-<x:anchor-alias value="CR"/>
-<x:anchor-alias value="LF"/>
-<x:anchor-alias value="SP"/>
-<x:anchor-alias value="HT"/>
-<x:anchor-alias value="CRLF"/>
-<x:anchor-alias value="LWS"/>
-<x:anchor-alias value="TEXT"/>
-<x:anchor-alias value="HEX"/>
-<x:anchor-alias value="token"/>
-<x:anchor-alias value="separators"/>
-<x:anchor-alias value="comment"/>
-<x:anchor-alias value="ctext"/>
-<x:anchor-alias value="quoted-string"/>
-<x:anchor-alias value="qdtext"/>
-<x:anchor-alias value="quoted-pair"/>
-<t>
- The following rules are used throughout this specification to
- describe basic parsing constructs. The US-ASCII coded character set
- is defined by ANSI X3.4-1986 <xref target="USASCII"/>.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="OCTET"/><iref primary="true" item="Grammar" subitem="CHAR"/><iref primary="true" item="Grammar" subitem="UPALPHA"/><iref primary="true" item="Grammar" subitem="LOALPHA"/><iref primary="true" item="Grammar" subitem="ALPHA"/><iref primary="true" item="Grammar" subitem="DIGIT"/><iref primary="true" item="Grammar" subitem="CTL"/><iref primary="true" item="Grammar" subitem="CR"/><iref primary="true" item="Grammar" subitem="LF"/><iref primary="true" item="Grammar" subitem="SP"/><iref primary="true" item="Grammar" subitem="HT"/>
- OCTET = <any 8-bit sequence of data>
- CHAR = <any US-ASCII character (octets 0 - 127)>
- UPALPHA = <any US-ASCII uppercase letter "A".."Z">
- LOALPHA = <any US-ASCII lowercase letter "a".."z">
- ALPHA = UPALPHA | LOALPHA
- DIGIT = <any US-ASCII digit "0".."9">
- CTL = <any US-ASCII control character
- (octets 0 - 31) and DEL (127)>
- CR = <US-ASCII CR, carriage return (13)>
- LF = <US-ASCII LF, linefeed (10)>
- SP = <US-ASCII SP, space (32)>
- HT = <US-ASCII HT, horizontal-tab (9)>
- <"> = <US-ASCII double-quote mark (34)>
-</artwork></figure>
-<t>
- HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
- protocol elements except the entity-body (see <xref target="tolerant.applications"/> for
- tolerant applications). The end-of-line marker within an entity-body
- is defined by its associated media type, as described in <xref target="media.types"/>.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="CRLF"/>
- CRLF = CR LF
-</artwork></figure>
-<t>
- HTTP/1.1 header field values can be folded onto multiple lines if the
- continuation line begins with a space or horizontal tab. All linear
- white space, including folding, has the same semantics as SP. A
- recipient &MAY; replace any linear white space with a single SP before
- interpreting the field value or forwarding the message downstream.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="LWS"/>
- LWS = [CRLF] 1*( SP | HT )
-</artwork></figure>
-<t>
- The TEXT rule is only used for descriptive field contents and values
- that are not intended to be interpreted by the message parser. Words
- of *TEXT &MAY; contain characters from character sets other than ISO-8859-1
- <xref target="ISO-8859"/> only when encoded according to the rules of RFC 2047
- <xref target="RFC2047"/>.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="TEXT"/>
- TEXT = <any OCTET except CTLs,
- but including LWS>
-</artwork></figure>
-<t>
- A CRLF is allowed in the definition of TEXT only as part of a header
- field continuation. It is expected that the folding LWS will be
- replaced with a single SP before interpretation of the TEXT value.
-</t>
-<t>
- Hexadecimal numeric characters are used in several protocol elements.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HEX"/>
- HEX = "A" | "B" | "C" | "D" | "E" | "F"
- | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
-</artwork></figure>
-<t>
- Many HTTP/1.1 header field values consist of words separated by LWS
- or special characters. These special characters &MUST; be in a quoted
- string to be used within a parameter value (as defined in
- <xref target="transfer.codings"/>).
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="token"/><iref primary="true" item="Grammar" subitem="separators"/>
- token = 1*<any CHAR except CTLs or separators>
- separators = "(" | ")" | "<" | ">" | "@"
- | "," | ";" | ":" | "\" | <">
- | "/" | "[" | "]" | "?" | "="
- | "{" | "}" | SP | HT
-</artwork></figure>
-<t>
- Comments can be included in some HTTP header fields by surrounding
- the comment text with parentheses. Comments are only allowed in
- fields containing "comment" as part of their field value definition.
- In all other fields, parentheses are considered part of the field
- value.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="comment"/><iref primary="true" item="Grammar" subitem="ctext"/>
- comment = "(" *( ctext | quoted-pair | comment ) ")"
- ctext = <any TEXT excluding "(" and ")">
-</artwork></figure>
-<t>
- A string of text is parsed as a single word if it is quoted using
- double-quote marks.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="quoted-string"/><iref primary="true" item="Grammar" subitem="qdtext"/>
- quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
- qdtext = <any TEXT except <">>
-</artwork></figure>
-<t>
- The backslash character ("\") &MAY; be used as a single-character
- quoting mechanism only within quoted-string and comment constructs.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="quoted-pair"/>
- quoted-pair = "\" CHAR
-</artwork></figure>
-</section>
-</section>
-
-<section title="Protocol Parameters">
-
-<section title="HTTP Version" anchor="http.version">
-<t>
- HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
- of the protocol. The protocol versioning policy is intended to allow
- the sender to indicate the format of a message and its capacity for
- understanding further HTTP communication, rather than the features
- obtained via that communication. No change is made to the version
- number for the addition of message components which do not affect
- communication behavior or which only add to extensible field values.
- The <minor> number is incremented when the changes made to the
- protocol add features which do not change the general message parsing
- algorithm, but which may add to the message semantics and imply
- additional capabilities of the sender. The <major> number is
- incremented when the format of a message within the protocol is
- changed. See RFC 2145 <xref target="RFC2145"/> for a fuller explanation.
-</t>
-<t>
- The version of an HTTP message is indicated by an HTTP-Version field
- in the first line of the message.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-Version"/>
- HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
-</artwork></figure>
-<t>
- Note that the major and minor numbers &MUST; be treated as separate
- integers and that each &MAY; be incremented higher than a single digit.
- Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
- lower than HTTP/12.3. Leading zeros &MUST; be ignored by recipients and
- &MUST-NOT; be sent.
-</t>
-<t>
- An application that sends a request or response message that includes
- HTTP-Version of "HTTP/1.1" &MUST; be at least conditionally compliant
- with this specification. Applications that are at least conditionally
- compliant with this specification &SHOULD; use an HTTP-Version of
- "HTTP/1.1" in their messages, and &MUST; do so for any message that is
- not compatible with HTTP/1.0. For more details on when to send
- specific HTTP-Version values, see RFC 2145 <xref target="RFC2145"/>.
-</t>
-<t>
- The HTTP version of an application is the highest HTTP version for
- which the application is at least conditionally compliant.
-</t>
-<t>
- Proxy and gateway applications need to be careful when forwarding
- messages in protocol versions different from that of the application.
- Since the protocol version indicates the protocol capability of the
- sender, a proxy/gateway &MUST-NOT; send a message with a version
- indicator which is greater than its actual version. If a higher
- version request is received, the proxy/gateway &MUST; either downgrade
- the request version, or respond with an error, or switch to tunnel
- behavior.
-</t>
-<t>
- Due to interoperability problems with HTTP/1.0 proxies discovered
- since the publication of RFC 2068 <xref target="RFC2068"/>, caching proxies MUST, gateways
- &MAY;, and tunnels &MUST-NOT; upgrade the request to the highest version
- they support. The proxy/gateway's response to that request &MUST; be in
- the same major version as the request.
-</t>
-<t>
- <list>
- <t>
- <x:h>Note:</x:h> Converting between versions of HTTP may involve modification
- of header fields required or forbidden by the versions involved.
- </t>
- </list>
-</t>
-</section>
-
-<section title="Uniform Resource Identifiers" anchor="uri">
-<t>
- URIs have been known by many names: WWW addresses, Universal Document
- Identifiers, Universal Resource Identifiers <xref target="RFC1630"/>, and finally the
- combination of Uniform Resource Locators (URL) <xref target="RFC1738"/> and Names (URN)
- <xref target="RFC1737"/>. As far as HTTP is concerned, Uniform Resource Identifiers are
- simply formatted strings which identify--via name, location, or any
- other characteristic--a resource.
-</t>
-
-<section title="General Syntax" anchor="general.syntax">
-<t>
- URIs in HTTP can be represented in absolute form or relative to some
- known base URI <xref target="RFC1808"/>, depending upon the context of their use. The two
- forms are differentiated by the fact that absolute URIs always begin
- with a scheme name followed by a colon. For definitive information on
- URL syntax and semantics, see "Uniform Resource Identifiers (URI):
- Generic Syntax and Semantics," RFC 2396 <xref target="RFC2396"/> (which replaces RFCs
- 1738 <xref target="RFC1738"/> and RFC 1808 <xref target="RFC1808"/>). This specification adopts the
- definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
- "host","abs_path", "rel_path", and "authority" from that
- specification.
-</t>
-<t>
- The HTTP protocol does not place any a priori limit on the length of
- a URI. Servers &MUST; be able to handle the URI of any resource they
- serve, and &SHOULD; be able to handle URIs of unbounded length if they
- provide GET-based forms that could generate such URIs. A server
- &SHOULD; return 414 (Request-URI Too Long) status if a URI is longer
- than the server can handle (see <xref target="status.414"/>).
-</t>
-<t>
- <list>
- <t>
- <x:h>Note:</x:h> Servers ought to be cautious about depending on URI lengths
- above 255 bytes, because some older client or proxy
- implementations might not properly support these lengths.
- </t>
- </list>
-</t>
-</section>
-
-<section title="http URL" anchor="http.url">
-<t>
- The "http" scheme is used to locate network resources via the HTTP
- protocol. This section defines the scheme-specific syntax and
- semantics for http URLs.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="http_URL"/>
-http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
-</artwork></figure>
-<t>
- If the port is empty or not given, port 80 is assumed. The semantics
- are that the identified resource is located at the server listening
- for TCP connections on that port of that host, and the Request-URI
- for the resource is abs_path (<xref target="request-uri"/>). The use of IP addresses
- in URLs &SHOULD; be avoided whenever possible (see RFC 1900 <xref target="RFC1900"/>). If
- the abs_path is not present in the URL, it &MUST; be given as "/" when
- used as a Request-URI for a resource (<xref target="request-uri"/>). If a proxy
-
- receives a host name which is not a fully qualified domain name, it
- &MAY; add its domain to the host name it received. If a proxy receives
- a fully qualified domain name, the proxy &MUST-NOT; change the host
- name.
-</t>
-</section>
-
-<section title="URI Comparison" anchor="uri.comparison">
-<t>
- When comparing two URIs to decide if they match or not, a client
- &SHOULD; use a case-sensitive octet-by-octet comparison of the entire
- URIs, with these exceptions:
- <list style="symbols">
- <t>A port that is empty or not given is equivalent to the default
- port for that URI-reference;</t>
- <t>Comparisons of host names &MUST; be case-insensitive;</t>
- <t>Comparisons of scheme names &MUST; be case-insensitive;</t>
- <t>An empty abs_path is equivalent to an abs_path of "/".</t>
- </list>
-</t>
-<t>
- Characters other than those in the "reserved" and "unsafe" sets (see
- RFC 2396 <xref target="RFC2396"/>) are equivalent to their ""%" HEX HEX" encoding.
-</t>
-<t>
- For example, the following three URIs are equivalent:
-</t>
-<figure><artwork type="example">
- http://abc.com:80/~smith/home.html
- http://ABC.com/%7Esmith/home.html
- http://ABC.com:/%7esmith/home.html
-</artwork></figure>
-</section>
-</section>
-
-<section title="Date/Time Formats">
-
-<section title="Full Date" anchor="full.date">
-<t>
- HTTP applications have historically allowed three different formats
- for the representation of date/time stamps:
-</t>
-<figure><artwork type="example">
- Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
- Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
- Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
-</artwork></figure>
-<t>
- The first format is preferred as an Internet standard and represents
- a fixed-length subset of that defined by RFC 1123 <xref target="RFC1123"/> (an update to
- RFC 822 <xref target="RFC822"/>). The second format is in common use, but is based on the
- obsolete RFC 850 <xref target="RFC1036"/> date format and lacks a four-digit year.
- HTTP/1.1 clients and servers that parse the date value &MUST; accept
- all three formats (for compatibility with HTTP/1.0), though they &MUST;
- only generate the RFC 1123 format for representing HTTP-date values
- in header fields. See <xref target="tolerant.applications"/> for further information.
-</t>
-<t><list><t>
- <x:h>Note:</x:h> Recipients of date values are encouraged to be robust in
- accepting date values that may have been sent by non-HTTP
- applications, as is sometimes the case when retrieving or posting
- messages via proxies/gateways to SMTP or NNTP.
-</t></list></t>
-<t>
- All HTTP date/time stamps &MUST; be represented in Greenwich Mean Time
- (GMT), without exception. For the purposes of HTTP, GMT is exactly
- equal to UTC (Coordinated Universal Time). This is indicated in the
- first two formats by the inclusion of "GMT" as the three-letter
- abbreviation for time zone, and &MUST; be assumed when reading the
- asctime format. HTTP-date is case sensitive and &MUST-NOT; include
- additional LWS beyond that specifically included as SP in the
- grammar.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-date"/><iref primary="true" item="Grammar" subitem="rfc1123-date"/><iref primary="true" item="Grammar" subitem="rfc850-date"/><iref primary="true" item="Grammar" subitem="asctime-date"/><iref primary="true" item="Grammar" subitem="date1"/><iref primary="true" item="Grammar" subitem="date2"/><iref primary="true" item="Grammar" subitem="date3"/><iref primary="true" item="Grammar" subitem="time"/><iref primary="true" item="Grammar" subitem="wkday"/><iref primary="true" item="Grammar" subitem="weekday"/><iref primary="true" item="Grammar" subitem="month"/>
- HTTP-date = rfc1123-date | rfc850-date | asctime-date
- rfc1123-date = wkday "," SP date1 SP time SP "GMT"
- rfc850-date = weekday "," SP date2 SP time SP "GMT"
- asctime-date = wkday SP date3 SP time SP 4DIGIT
- date1 = 2DIGIT SP month SP 4DIGIT
- ; day month year (e.g., 02 Jun 1982)
- date2 = 2DIGIT "-" month "-" 2DIGIT
- ; day-month-year (e.g., 02-Jun-82)
- date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
- ; month day (e.g., Jun 2)
- time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
- ; 00:00:00 - 23:59:59
- wkday = "Mon" | "Tue" | "Wed"
- | "Thu" | "Fri" | "Sat" | "Sun"
- weekday = "Monday" | "Tuesday" | "Wednesday"
- | "Thursday" | "Friday" | "Saturday" | "Sunday"
- month = "Jan" | "Feb" | "Mar" | "Apr"
- | "May" | "Jun" | "Jul" | "Aug"
- | "Sep" | "Oct" | "Nov" | "Dec"
-</artwork></figure>
-<t>
- <x:h>Note:</x:h> HTTP requirements for the date/time stamp format apply only
- to their usage within the protocol stream. Clients and servers are
- not required to use these formats for user presentation, request
- logging, etc.
-</t>
-</section>
-
-<section title="Delta Seconds">
-<t>
- Some HTTP header fields allow a time value to be specified as an
- integer number of seconds, represented in decimal, after the time
- that the message was received.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="delta-seconds"/>
- delta-seconds = 1*DIGIT
-</artwork></figure>
-</section>
-</section>
-
-<section title="Character Sets" anchor="character.sets">
-<t>
- HTTP uses the same definition of the term "character set" as that
- described for MIME:
-</t>
-<t>
- The term "character set" is used in this document to refer to a
- method used with one or more tables to convert a sequence of octets
- into a sequence of characters. Note that unconditional conversion in
- the other direction is not required, in that not all characters may
- be available in a given character set and a character set may provide
- more than one sequence of octets to represent a particular character.
- This definition is intended to allow various kinds of character
- encoding, from simple single-table mappings such as US-ASCII to
- complex table switching methods such as those that use ISO-2022's
- techniques. However, the definition associated with a MIME character
- set name &MUST; fully specify the mapping to be performed from octets
- to characters. In particular, use of external profiling information
- to determine the exact mapping is not permitted.
-</t>
-<t><list><t>
- <x:h>Note:</x:h> This use of the term "character set" is more commonly
- referred to as a "character encoding." However, since HTTP and
- MIME share the same registry, it is important that the terminology
- also be shared.
-</t></list></t>
-<t>
- HTTP character sets are identified by case-insensitive tokens. The
- complete set of tokens is defined by the IANA Character Set registry
- <xref target="RFC1700"/>.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="charset"/>
- charset = token
-</artwork></figure>
-<t>
- Although HTTP allows an arbitrary token to be used as a charset
- value, any token that has a predefined value within the IANA
- Character Set registry <xref target="RFC1700"/> &MUST; represent the character set defined
- by that registry. Applications &SHOULD; limit their use of character
- sets to those defined by the IANA registry.
-</t>
-<t>
- Implementors should be aware of IETF character set requirements <xref target="RFC2279"/>
- <xref target="RFC2277"/>.
-</t>
-
-<section title="Missing Charset" anchor="missing.charset">
-<t>
- Some HTTP/1.0 software has interpreted a Content-Type header without
- charset parameter incorrectly to mean "recipient should guess."
- Senders wishing to defeat this behavior &MAY; include a charset
- parameter even when the charset is ISO-8859-1 and &SHOULD; do so when
- it is known that it will not confuse the recipient.
-</t>
-<t>
- Unfortunately, some older HTTP/1.0 clients did not deal properly with
- an explicit charset parameter. HTTP/1.1 recipients &MUST; respect the
- charset label provided by the sender; and those user agents that have
- a provision to "guess" a charset &MUST; use the charset from the
- content-type field if they support that charset, rather than the
- recipient's preference, when initially displaying a document. See
- <xref target="canonicalization.and.text.defaults"/>.
-</t>
-</section>
-</section>
-
-<section title="Content Codings" anchor="content.codings">
-<t>
- Content coding values indicate an encoding transformation that has
- been or can be applied to an entity. Content codings are primarily
- used to allow a document to be compressed or otherwise usefully
- transformed without losing the identity of its underlying media type
- and without loss of information. Frequently, the entity is stored in
- coded form, transmitted directly, and only decoded by the recipient.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="content-coding"/>
- content-coding = token
-</artwork></figure>
-<t>
- All content-coding values are case-insensitive. HTTP/1.1 uses
- content-coding values in the Accept-Encoding (<xref target="header.accept-encoding"/>) and
- Content-Encoding (<xref target="header.content-encoding"/>) header fields. Although the value
- describes the content-coding, what is more important is that it
- indicates what decoding mechanism will be required to remove the
- encoding.
-</t>
-<t>
- The Internet Assigned Numbers Authority (IANA) acts as a registry for
- content-coding value tokens. Initially, the registry contains the
- following tokens:
-</t>
-<t>
- gzip<iref item="gzip"/>
- <list>
- <t>
- An encoding format produced by the file compression program
- "gzip" (GNU zip) as described in RFC 1952 <xref target="RFC1952"/>. This format is a
- Lempel-Ziv coding (LZ77) with a 32 bit CRC.
- </t>
- </list>
-</t>
-<t>
- compress<iref item="compress"/>
- <list><t>
- The encoding format produced by the common UNIX file compression
- program "compress". This format is an adaptive Lempel-Ziv-Welch
- coding (LZW).
-</t><t>
- Use of program names for the identification of encoding formats
- is not desirable and is discouraged for future encodings. Their
- use here is representative of historical practice, not good
- design. For compatibility with previous implementations of HTTP,
- applications &SHOULD; consider "x-gzip" and "x-compress" to be
- equivalent to "gzip" and "compress" respectively.
- </t></list>
-</t>
-<t>
- deflate<iref item="deflate"/>
- <list><t>
- The "zlib" format defined in RFC 1950 <xref target="RFC1950"/> in combination with
- the "deflate" compression mechanism described in RFC 1951 <xref target="RFC1951"/>.
- </t></list>
-</t>
-<t>
- identity<iref item="identity"/>
- <list><t>
- The default (identity) encoding; the use of no transformation
- whatsoever. This content-coding is used only in the Accept-Encoding
- header, and &SHOULD-NOT; be used in the Content-Encoding
- header.
- </t></list>
-</t>
-<t>
- New content-coding value tokens &SHOULD; be registered; to allow
- interoperability between clients and servers, specifications of the
- content coding algorithms needed to implement a new value &SHOULD; be
- publicly available and adequate for independent implementation, and
- conform to the purpose of content coding defined in this section.
-</t>
-</section>
-
-<section title="Transfer Codings" anchor="transfer.codings">
-<t>
- Transfer-coding values are used to indicate an encoding
- transformation that has been, can be, or may need to be applied to an
- entity-body in order to ensure "safe transport" through the network.
- This differs from a content coding in that the transfer-coding is a
- property of the message, not of the original entity.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="transfer-coding"/><iref primary="true" item="Grammar" subitem="transfer-extension"/>
- transfer-coding = "chunked" | transfer-extension
- transfer-extension = token *( ";" parameter )
-</artwork></figure>
-<t>
- Parameters are in the form of attribute/value pairs.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="parameter"/><iref primary="true" item="Grammar" subitem="attribute"/><iref primary="true" item="Grammar" subitem="value"/>
- parameter = attribute "=" value
- attribute = token
- value = token | quoted-string
-</artwork></figure>
-<t>
- All transfer-coding values are case-insensitive. HTTP/1.1 uses
- transfer-coding values in the TE header field (<xref target="header.te"/>) and in
- the Transfer-Encoding header field (<xref target="header.transfer-encoding"/>).
-</t>
-<t>
- Whenever a transfer-coding is applied to a message-body, the set of
- transfer-codings &MUST; include "chunked", unless the message is
- terminated by closing the connection. When the "chunked" transfer-coding
- is used, it &MUST; be the last transfer-coding applied to the
- message-body. The "chunked" transfer-coding &MUST-NOT; be applied more
- than once to a message-body. These rules allow the recipient to
- determine the transfer-length of the message (<xref target="message.length"/>).
-</t>
-<t>
- Transfer-codings are analogous to the Content-Transfer-Encoding
- values of MIME <xref target="RFC2045"/>, which were designed to enable safe transport of
- binary data over a 7-bit transport service. However, safe transport
- has a different focus for an 8bit-clean transfer protocol. In HTTP,
- the only unsafe characteristic of message-bodies is the difficulty in
- determining the exact body length (<xref target="entity.length"/>), or the desire to
- encrypt data over a shared transport.
-</t>
-<t>
- The Internet Assigned Numbers Authority (IANA) acts as a registry for
- transfer-coding value tokens. Initially, the registry contains the
- following tokens: "chunked" (<xref target="chunked.transfer.encoding"/>), "identity" (section
- 3.6.2), "gzip" (<xref target="content.codings"/>), "compress" (<xref target="content.codings"/>), and "deflate"
- (<xref target="content.codings"/>).
-</t>
-<t>
- New transfer-coding value tokens &SHOULD; be registered in the same way
- as new content-coding value tokens (<xref target="content.codings"/>).
-</t>
-<t>
- A server which receives an entity-body with a transfer-coding it does
- not understand &SHOULD; return 501 (Unimplemented), and close the
- connection. A server &MUST-NOT; send transfer-codings to an HTTP/1.0
- client.
-</t>
-
-<section title="Chunked Transfer Coding" anchor="chunked.transfer.encoding">
-<t>
- The chunked encoding modifies the body of a message in order to
- transfer it as a series of chunks, each with its own size indicator,
- followed by an &OPTIONAL; trailer containing entity-header fields. This
- allows dynamically produced content to be transferred along with the
- information necessary for the recipient to verify that it has
- received the full message.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Chunked-Body"/><iref primary="true" item="Grammar" subitem="chunk"/><iref primary="true" item="Grammar" subitem="chunk-size"/><iref primary="true" item="Grammar" subitem="last-chunk"/><iref primary="true" item="Grammar" subitem="chunk-extension"/><iref primary="true" item="Grammar" subitem="chunk-ext-name"/><iref primary="true" item="Grammar" subitem="chunk-ext-val"/><iref primary="true" item="Grammar" subitem="chunk-data"/><iref primary="true" item="Grammar" subitem="trailer"/>
- Chunked-Body = *chunk
- last-chunk
- trailer
- CRLF
-
- chunk = chunk-size [ chunk-extension ] CRLF
- chunk-data CRLF
- chunk-size = 1*HEX
- last-chunk = 1*("0") [ chunk-extension ] CRLF
-
- chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
- chunk-ext-name = token
- chunk-ext-val = token | quoted-string
- chunk-data = chunk-size(OCTET)
- trailer = *(entity-header CRLF)
-</artwork></figure>
-<t>
- The chunk-size field is a string of hex digits indicating the size of
- the chunk. The chunked encoding is ended by any chunk whose size is
- zero, followed by the trailer, which is terminated by an empty line.
-</t>
-<t>
- The trailer allows the sender to include additional HTTP header
- fields at the end of the message. The Trailer header field can be
- used to indicate which header fields are included in a trailer (see
- <xref target="header.trailer"/>).
-</t>
-<t>
- A server using chunked transfer-coding in a response &MUST-NOT; use the
- trailer for any header fields unless at least one of the following is
- true:
- <list style="numbers">
- <t>the request included a TE header field that indicates "trailers" is
- acceptable in the transfer-coding of the response, as described in
- <xref target="header.te"/>; or,</t>
-
- <t>the server is the origin server for the response, the trailer
- fields consist entirely of optional metadata, and the recipient
- could use the message (in a manner acceptable to the origin server)
- without receiving this metadata. In other words, the origin server
- is willing to accept the possibility that the trailer fields might
- be silently discarded along the path to the client.</t>
- </list>
-</t>
-<t>
- This requirement prevents an interoperability failure when the
- message is being received by an HTTP/1.1 (or later) proxy and
- forwarded to an HTTP/1.0 recipient. It avoids a situation where
- compliance with the protocol would have necessitated a possibly
- infinite buffer on the proxy.
-</t>
-<t>
- An example process for decoding a Chunked-Body is presented in
- <xref target="introduction.of.transfer-encoding"/>.
-</t>
-<t>
- All HTTP/1.1 applications &MUST; be able to receive and decode the
- "chunked" transfer-coding, and &MUST; ignore chunk-extension extensions
- they do not understand.
-</t>
-</section>
-</section>
-
-<section title="Media Types" anchor="media.types">
-<t>
- HTTP uses Internet Media Types <xref target="RFC1590"/> in the Content-Type (<xref target="header.content-type"/>)
- and Accept (<xref target="header.accept"/>) header fields in order to provide
- open and extensible data typing and type negotiation.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="media-type"/><iref primary="true" item="Grammar" subitem="type"/><iref primary="true" item="Grammar" subitem="subtype"/>
- media-type = type "/" subtype *( ";" parameter )
- type = token
- subtype = token
-</artwork></figure>
-<t>
- Parameters &MAY; follow the type/subtype in the form of attribute/value
- pairs (as defined in <xref target="transfer.codings"/>).
-</t>
-<t>
- The type, subtype, and parameter attribute names are case-insensitive.
- Parameter values might or might not be case-sensitive,
- depending on the semantics of the parameter name. Linear white space
- (LWS) &MUST-NOT; be used between the type and subtype, nor between an
- attribute and its value. The presence or absence of a parameter might
- be significant to the processing of a media-type, depending on its
- definition within the media type registry.
-</t>
-<t>
- Note that some older HTTP applications do not recognize media type
- parameters. When sending data to older HTTP applications,
- implementations &SHOULD; only use media type parameters when they are
- required by that type/subtype definition.
-</t>
-<t>
- Media-type values are registered with the Internet Assigned Number
- Authority (IANA <xref target="RFC1700"/>). The media type registration process is
- outlined in RFC 1590 <xref target="RFC1590"/>. Use of non-registered media types is
- discouraged.
-</t>
-
-<section title="Canonicalization and Text Defaults" anchor="canonicalization.and.text.defaults">
-<t>
- Internet media types are registered with a canonical form. An
- entity-body transferred via HTTP messages &MUST; be represented in the
- appropriate canonical form prior to its transmission except for
- "text" types, as defined in the next paragraph.
-</t>
-<t>
- When in canonical form, media subtypes of the "text" type use CRLF as
- the text line break. HTTP relaxes this requirement and allows the
- transport of text media with plain CR or LF alone representing a line
- break when it is done consistently for an entire entity-body. HTTP
- applications &MUST; accept CRLF, bare CR, and bare LF as being
- representative of a line break in text media received via HTTP. In
- addition, if the text is represented in a character set that does not
- use octets 13 and 10 for CR and LF respectively, as is the case for
- some multi-byte character sets, HTTP allows the use of whatever octet
- sequences are defined by that character set to represent the
- equivalent of CR and LF for line breaks. This flexibility regarding
- line breaks applies only to text media in the entity-body; a bare CR
- or LF &MUST-NOT; be substituted for CRLF within any of the HTTP control
- structures (such as header fields and multipart boundaries).
-</t>
-<t>
- If an entity-body is encoded with a content-coding, the underlying
- data &MUST; be in a form defined above prior to being encoded.
-</t>
-<t>
- The "charset" parameter is used with some media types to define the
- character set (<xref target="character.sets"/>) of the data. When no explicit charset
- parameter is provided by the sender, media subtypes of the "text"
- type are defined to have a default charset value of "ISO-8859-1" when
- received via HTTP. Data in character sets other than "ISO-8859-1" or
- its subsets &MUST; be labeled with an appropriate charset value. See
- <xref target="missing.charset"/> for compatibility problems.
-</t>
-</section>
-
-<section title="Multipart Types" anchor="multipart.types">
-<t>
- MIME provides for a number of "multipart" types -- encapsulations of
- one or more entities within a single message-body. All multipart
- types share a common syntax, as defined in section <xref target="RFC2046" x:sec="5.1.1" x:fmt="number"/> of RFC 2046
- <xref target="RFC2046"/>, and &MUST; include a boundary parameter as part of the media type
- value. The message body is itself a protocol element and &MUST;
- therefore use only CRLF to represent line breaks between body-parts.
- Unlike in RFC 2046, the epilogue of any multipart message &MUST; be
- empty; HTTP applications &MUST-NOT; transmit the epilogue (even if the
- original multipart contains an epilogue). These restrictions exist in
- order to preserve the self-delimiting nature of a multipart message-body,
- wherein the "end" of the message-body is indicated by the
- ending multipart boundary.
-</t>
-<t>
- In general, HTTP treats a multipart message-body no differently than
- any other media type: strictly as payload. The one exception is the
- "multipart/byteranges" type (<xref target="internet.media.type.multipart.byteranges"/>) when it appears in a 206
- (Partial Content) response, which will be interpreted by some HTTP
- caching mechanisms as described in sections <xref target="combining.byte.ranges" format="counter"/>
- and <xref target="header.content-range" format="counter"/>. In all
- other cases, an HTTP user agent &SHOULD; follow the same or similar
- behavior as a MIME user agent would upon receipt of a multipart type.
- The MIME header fields within each body-part of a multipart message-body
- do not have any significance to HTTP beyond that defined by
- their MIME semantics.
-</t>
-<t>
- In general, an HTTP user agent &SHOULD; follow the same or similar
- behavior as a MIME user agent would upon receipt of a multipart type.
- If an application receives an unrecognized multipart subtype, the
- application &MUST; treat it as being equivalent to "multipart/mixed".
-</t>
-<t><list><t>
- <x:h>Note:</x:h> The "multipart/form-data" type has been specifically defined
- for carrying form data suitable for processing via the POST
- request method, as described in RFC 1867 <xref target="RFC1867"/>.
-</t></list></t>
-</section>
-</section>
-
-<section title="Product Tokens" anchor="product.tokens">
-<t>
- Product tokens are used to allow communicating applications to
- identify themselves by software name and version. Most fields using
- product tokens also allow sub-products which form a significant part
- of the application to be listed, separated by white space. By
- convention, the products are listed in order of their significance
- for identifying the application.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="product"/><iref primary="true" item="Grammar" subitem="product-version"/>
- product = token ["/" product-version]
- product-version = token
-</artwork></figure>
-<t>
- Examples:
-</t>
-<figure><artwork type="example">
- User-Agent: CERN-LineMode/2.15 libwww/2.17b3
- Server: Apache/0.8.4
-</artwork></figure>
-<t>
- Product tokens &SHOULD; be short and to the point. They &MUST-NOT; be
- used for advertising or other non-essential information. Although any
- token character &MAY; appear in a product-version, this token &SHOULD;
- only be used for a version identifier (i.e., successive versions of
- the same product &SHOULD; only differ in the product-version portion of
- the product value).
-</t>
-</section>
-
-<section title="Quality Values" anchor="quality.values">
-<t>
- HTTP content negotiation (<xref target="content.negotiation"/>) uses short "floating point"
- numbers to indicate the relative importance ("weight") of various
- negotiable parameters. A weight is normalized to a real number in
- the range 0 through 1, where 0 is the minimum and 1 the maximum
- value. If a parameter has a quality value of 0, then content with
- this parameter is `not acceptable' for the client. HTTP/1.1
- applications &MUST-NOT; generate more than three digits after the
- decimal point. User configuration of these values &SHOULD; also be
- limited in this fashion.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="qvalue"/>
- qvalue = ( "0" [ "." 0*3DIGIT ] )
- | ( "1" [ "." 0*3("0") ] )
-</artwork></figure>
-<t>
- "Quality values" is a misnomer, since these values merely represent
- relative degradation in desired quality.
-</t>
-</section>
-
-<section title="Language Tags" anchor="language.tags">
-<t>
- A language tag identifies a natural language spoken, written, or
- otherwise conveyed by human beings for communication of information
- to other human beings. Computer languages are explicitly excluded.
- HTTP uses language tags within the Accept-Language and Content-Language
- fields.
-</t>
-<t>
- The syntax and registry of HTTP language tags is the same as that
- defined by RFC 1766 <xref target="RFC1766"/>. In summary, a language tag is composed of 1
- or more parts: A primary language tag and a possibly empty series of
- subtags:
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="language-tag"/><iref primary="true" item="Grammar" subitem="primary-tag"/><iref primary="true" item="Grammar" subitem="subtag"/>
- language-tag = primary-tag *( "-" subtag )
- primary-tag = 1*8ALPHA
- subtag = 1*8ALPHA
-</artwork></figure>
-<t>
- White space is not allowed within the tag and all tags are case-insensitive.
- The name space of language tags is administered by the
- IANA. Example tags include:
-</t>
-<figure><artwork type="example">
- en, en-US, en-cockney, i-cherokee, x-pig-latin
-</artwork></figure>
-<t>
- where any two-letter primary-tag is an ISO-639 language abbreviation
- and any two-letter initial subtag is an ISO-3166 country code. (The
- last three tags above are not registered tags; all but the last are
- examples of tags which could be registered in future.)
-</t>
-</section>
-
-<section title="Entity Tags" anchor="entity.tags">
-<t>
- Entity tags are used for comparing two or more entities from the same
- requested resource. HTTP/1.1 uses entity tags in the ETag (<xref target="header.etag"/>),
- If-Match (<xref target="header.if-match"/>), If-None-Match (<xref target="header.if-none-match"/>), and
- If-Range (<xref target="header.if-range"/>) header fields. The definition of how they
- are used and compared as cache validators is in <xref target="weak.and.strong.validators"/>. An
- entity tag consists of an opaque quoted string, possibly prefixed by
- a weakness indicator.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="entity-tag"/><iref primary="true" item="Grammar" subitem="weak"/><iref primary="true" item="Grammar" subitem="opaque-tag"/>
- entity-tag = [ weak ] opaque-tag
- weak = "W/"
- opaque-tag = quoted-string
-</artwork></figure>
-<t>
- A "strong entity tag" &MAY; be shared by two entities of a resource
- only if they are equivalent by octet equality.
-</t>
-<t>
- A "weak entity tag," indicated by the "W/" prefix, &MAY; be shared by
- two entities of a resource only if the entities are equivalent and
- could be substituted for each other with no significant change in
- semantics. A weak entity tag can only be used for weak comparison.
-</t>
-<t>
- An entity tag &MUST; be unique across all versions of all entities
- associated with a particular resource. A given entity tag value &MAY;
- be used for entities obtained by requests on different URIs. The use
- of the same entity tag value in conjunction with entities obtained by
- requests on different URIs does not imply the equivalence of those
- entities.
-</t>
-</section>
-
-<section title="Range Units" anchor="range.units">
-<t>
- HTTP/1.1 allows a client to request that only part (a range of) the
- response entity be included within the response. HTTP/1.1 uses range
- units in the Range (<xref target="header.range"/>) and Content-Range (<xref target="header.content-range"/>)
- header fields. An entity can be broken down into subranges according
- to various structural units.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="range-unit"/><iref primary="true" item="Grammar" subitem="bytes-unit"/><iref primary="true" item="Grammar" subitem="other-range-unit"/>
- range-unit = bytes-unit | other-range-unit
- bytes-unit = "bytes"
- other-range-unit = token
-</artwork></figure>
-<t>
- The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
- implementations &MAY; ignore ranges specified using other units.
-</t>
-<t>
- HTTP/1.1 has been designed to allow implementations of applications
- that do not depend on knowledge of ranges.
-</t>
-</section>
-</section>
-
-
-
-
-<section title="HTTP Message" anchor="httpmessage">
-
-<section title="Message Types">
-<t>
- HTTP messages consist of requests from client to server and responses
- from server to client.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-message"/>
- HTTP-message = Request | Response ; HTTP/1.1 messages
-</artwork></figure>
-<t>
- Request (<xref target="request"/>) and Response (<xref target="response"/>) messages use the generic
- message format of RFC 822 <xref target="RFC822"/> for transferring entities (the payload
- of the message). Both types of message consist of a start-line, zero
- or more header fields (also known as "headers"), an empty line (i.e.,
- a line with nothing preceding the CRLF) indicating the end of the
- header fields, and possibly a message-body.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="generic-message"/><iref primary="true" item="Grammar" subitem="start-line"/>
- generic-message = start-line
- *(message-header CRLF)
- CRLF
- [ message-body ]
- start-line = Request-Line | Status-Line
-</artwork></figure>
-<t>
- In the interest of robustness, servers &SHOULD; ignore any empty
- line(s) received where a Request-Line is expected. In other words, if
- the server is reading the protocol stream at the beginning of a
- message and receives a CRLF first, it should ignore the CRLF.
-</t>
-<t>
- Certain buggy HTTP/1.0 client implementations generate extra CRLF's
- after a POST request. To restate what is explicitly forbidden by the
- BNF, an HTTP/1.1 client &MUST-NOT; preface or follow a request with an
- extra CRLF.
-</t>
-</section>
-
-<section title="Message Headers" anchor="message.headers">
-<t>
- HTTP header fields, which include general-header (<xref target="general.header.fields"/>),
- request-header (<xref target="request.header.fields"/>), response-header (<xref target="response.header.fields"/>), and
- entity-header (<xref target="entity.header.fields"/>) fields, follow the same generic format as
- that given in <xref target="RFC822" x:fmt="sec" x:sec="3.1"/> of RFC 822 <xref target="RFC822"/>. Each header field consists
- of a name followed by a colon (":") and the field value. Field names
- are case-insensitive. The field value &MAY; be preceded by any amount
- of LWS, though a single SP is preferred. Header fields can be
- extended over multiple lines by preceding each extra line with at
- least one SP or HT. Applications ought to follow "common form", where
- one is known or indicated, when generating HTTP constructs, since
- there might exist some implementations that fail to accept anything
- beyond the common forms.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="message-header"/><iref primary="true" item="Grammar" subitem="field-name"/><iref primary="true" item="Grammar" subitem="field-value"/><iref primary="true" item="Grammar" subitem="field-content"/>
- message-header = field-name ":" [ field-value ]
- field-name = token
- field-value = *( field-content | LWS )
- field-content = <the OCTETs making up the field-value
- and consisting of either *TEXT or combinations
- of token, separators, and quoted-string>
-</artwork></figure>
-<t>
- The field-content does not include any leading or trailing LWS:
- linear white space occurring before the first non-whitespace
- character of the field-value or after the last non-whitespace
- character of the field-value. Such leading or trailing LWS &MAY; be
- removed without changing the semantics of the field value. Any LWS
- that occurs between field-content &MAY; be replaced with a single SP
- before interpreting the field value or forwarding the message
- downstream.
-</t>
-<t>
- The order in which header fields with differing field names are
- received is not significant. However, it is "good practice" to send
- general-header fields first, followed by request-header or response-header
- fields, and ending with the entity-header fields.
-</t>
-<t>
- Multiple message-header fields with the same field-name &MAY; be
- present in a message if and only if the entire field-value for that
- header field is defined as a comma-separated list [i.e., #(values)].
- It &MUST; be possible to combine the multiple header fields into one
- "field-name: field-value" pair, without changing the semantics of the
- message, by appending each subsequent field-value to the first, each
- separated by a comma. The order in which header fields with the same
- field-name are received is therefore significant to the
- interpretation of the combined field value, and thus a proxy &MUST-NOT;
- change the order of these field values when a message is forwarded.
-</t>
-</section>
-
-<section title="Message Body" anchor="message.body">
-<t>
- The message-body (if any) of an HTTP message is used to carry the
- entity-body associated with the request or response. The message-body
- differs from the entity-body only when a transfer-coding has been
- applied, as indicated by the Transfer-Encoding header field (<xref target="header.transfer-encoding"/>).
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="message-body"/>
- message-body = entity-body
- | <entity-body encoded as per Transfer-Encoding>
-</artwork></figure>
-<t>
- Transfer-Encoding &MUST; be used to indicate any transfer-codings
- applied by an application to ensure safe and proper transfer of the
- message. Transfer-Encoding is a property of the message, not of the
- entity, and thus &MAY; be added or removed by any application along the
- request/response chain. (However, <xref target="transfer.codings"/> places restrictions on
- when certain transfer-codings may be used.)
-</t>
-<t>
- The rules for when a message-body is allowed in a message differ for
- requests and responses.
-</t>
-<t>
- The presence of a message-body in a request is signaled by the
- inclusion of a Content-Length or Transfer-Encoding header field in
- the request's message-headers. A message-body &MUST-NOT; be included in
- a request if the specification of the request method (<xref target="method"/>)
- does not allow sending an entity-body in requests. A server &SHOULD;
- read and forward a message-body on any request; if the request method
- does not include defined semantics for an entity-body, then the
- message-body &SHOULD; be ignored when handling the request.
-</t>
-<t>
- For response messages, whether or not a message-body is included with
- a message is dependent on both the request method and the response
- status code (<xref target="status.code.and.reason.phrase"/>). All responses to the HEAD request method
- &MUST-NOT; include a message-body, even though the presence of entity-header
- fields might lead one to believe they do. All 1xx
- (informational), 204 (no content), and 304 (not modified) responses
- &MUST-NOT; include a message-body. All other responses do include a
- message-body, although it &MAY; be of zero length.
-</t>
-</section>
-
-<section title="Message Length" anchor="message.length">
-<t>
- The transfer-length of a message is the length of the message-body as
- it appears in the message; that is, after any transfer-codings have
- been applied. When a message-body is included with a message, the
- transfer-length of that body is determined by one of the following
- (in order of precedence):
-</t>
-<t>
- <list style="numbers">
- <x:lt><t>
- Any response message which "&MUST-NOT;" include a message-body (such
- as the 1xx, 204, and 304 responses and any response to a HEAD
- request) is always terminated by the first empty line after the
- header fields, regardless of the entity-header fields present in
- the message.
- </t></x:lt>
- <x:lt><t>
- If a Transfer-Encoding header field (<xref target="header.transfer-encoding"/>) is present and
- has any value other than "identity", then the transfer-length is
- defined by use of the "chunked" transfer-coding (<xref target="transfer.codings"/>),
- unless the message is terminated by closing the connection.
- </t></x:lt>
- <x:lt><t>
- If a Content-Length header field (<xref target="header.content-length"/>) is present, its
- decimal value in OCTETs represents both the entity-length and the
- transfer-length. The Content-Length header field &MUST-NOT; be sent
[... 9582 lines stripped ...]
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@labs.apache.org
For additional commands, e-mail: commits-help@labs.apache.org