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 [6/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/p5-range.xml
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p5-range.xml?rev=583020&r1=583019&r2=583020&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p5-range.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p5-range.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,8 @@
<!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 messaging "[Part 1]">
+ <!ENTITY weak-and-strong-validators "[Part 4]">
]>
<?rfc toc="yes" ?>
<?rfc symrefs="no" ?>
@@ -20,11 +22,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-p5-range-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 5: Range Requests and Partial Responses</title>
<author initials="R." surname="Fielding" fullname="Roy T. Fielding">
<organization abbrev="UC Irvine">Department of Information and Computer Science</organization>
@@ -126,10613 +129,606 @@
</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 5 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 5 defines range-specific requests and
+ the rules for constructing and combining responses to those requests.
</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 range requests,
+ partial responses, and the multipart/byteranges media type. Right now
+ it only includes the extracted relevant sections of
+ <xref target="RFC2616">RFC 2616</xref> without edit.
</t>
</section>
-<section title="Requirements">
+<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 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"/>.
+ The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
+ implementations &MAY; ignore ranges specified using other units.
</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."
+ HTTP/1.1 has been designed to allow implementations of applications
+ that do not depend on knowledge of ranges.
</t>
</section>
-<section title="Terminology">
+<section title="206 Partial Content" anchor="status.206">
+ <iref primary="true" item="206 Partial Content (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="206 Partial Content" x:for-anchor=""/>
<t>
- This specification uses a number of terms to refer to the roles
- played by participants in, and objects of, the HTTP communication.
+ The server has fulfilled the partial GET request for the resource.
+ The request &MUST; have included a Range header field (<xref target="header.range"/>)
+ indicating the desired range, and &MAY; have included an If-Range
+ header field (<xref target="header.if-range"/>) to make the request conditional.
</t>
<t>
- <iref item="connection"/>
- <x:dfn>connection</x:dfn>
- <list>
+ The response &MUST; include the following header fields:
+ <list style="symbols">
<t>
- A transport layer virtual circuit established between two programs
- for the purpose of communication.
+ Either a Content-Range header field (<xref target="header.content-range"/>) indicating
+ the range included with this response, or a multipart/byteranges
+ Content-Type including Content-Range fields for each part. If a
+ Content-Length header field is present in the response, its
+ value &MUST; match the actual number of OCTETs transmitted in the
+ message-body.
</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.
+ Date
</t>
- </list>
-</t>
-<t>
- <iref item="request"/>
- <x:dfn>request</x:dfn>
- <list>
<t>
- An HTTP request message, as defined in <xref target="request"/>.
+ ETag and/or Content-Location, if the header would have been sent
+ in a 200 response to the same request
</t>
- </list>
-</t>
-<t>
- <iref item="response"/>
- <x:dfn>response</x:dfn>
- <list>
<t>
- An HTTP response message, as defined in <xref target="response"/>.
+ Expires, Cache-Control, and/or Vary, if the field-value might
+ differ from that sent in any previous response for the same
+ variant
</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>
+ If the 206 response is the result of an If-Range request that used a
+ strong cache validator (see &weak-and-strong-validators;), the response &SHOULD-NOT;
+ include other entity-headers. If the response is the result of an
+ If-Range request that used a weak validator, the response &MUST-NOT;
+ include other entity-headers; this prevents inconsistencies between
+ cached entity-bodies and updated headers. Otherwise, the response
+ &MUST; include all of the entity-headers that would have been returned
+ with a 200 (OK) response to the same request.
</t>
<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>
+ A cache &MUST-NOT; combine a 206 response with other previously cached
+ content if the ETag or Last-Modified headers do not match exactly,
+ see <xref target="combining.byte.ranges" format="counter"/>.
</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>
+ A cache that does not support the Range and Content-Range headers
+ &MUST-NOT; cache 206 (Partial) responses.
</t>
+</section>
+
+<section title="416 Requested Range Not Satisfiable" anchor="status.416">
+ <iref primary="true" item="416 Requested Range Not Satisfiable (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="416 Requested Range Not Satisfiable" x:for-anchor=""/>
<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>
+ A server &SHOULD; return a response with this status code if a request
+ included a Range request-header field (<xref target="header.range"/>), and none of
+ the range-specifier values in this field overlap the current extent
+ of the selected resource, and the request did not include an If-Range
+ request-header field. (For byte-ranges, this means that the first-byte-pos
+ of all of the byte-range-spec values were greater than the
+ current length of the selected resource.)
</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>
+ When this status code is returned for a byte-range request, the
+ response &SHOULD; include a Content-Range entity-header field
+ specifying the current length of the selected resource (see <xref target="header.content-range"/>).
+ This response &MUST-NOT; use the multipart/byteranges content-type.
</t>
+</section>
+
+<section title="Combining Byte Ranges" anchor="combining.byte.ranges">
<t>
- <iref item="client"/>
- <x:dfn>client</x:dfn>
- <list>
- <t>
- A program that establishes connections for the purpose of sending
- requests.
- </t>
- </list>
+ A response might transfer only a subrange of the bytes of an entity-body,
+ either because the request included one or more Range
+ specifications, or because a connection was broken prematurely. After
+ several such transfers, a cache might have received several ranges of
+ the same entity-body.
</t>
<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>
+ If a cache has a stored non-empty set of subranges for an entity, and
+ an incoming response transfers another subrange, the cache &MAY;
+ combine the new subrange with the existing set if both the following
+ conditions are met:
+ <list style="symbols">
+ <t>Both the incoming response and the cache entry have a cache
+ validator.</t>
+ <t>The two cache validators match using the strong comparison
+ function (see &weak-and-strong-validators;).</t>
</list>
</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>
+ If either requirement is not met, the cache &MUST; use only the most
+ recent partial response (based on the Date values transmitted with
+ every response, and using the incoming response if these values are
+ equal or missing), and &MUST; discard the other partial information.
</t>
+</section>
+
+<section title="Header Field Definitions">
<t>
- <iref item="origin server"/>
- <x:dfn>origin server</x:dfn>
- <list>
- <t>
- The server on which a given resource resides or is to be created.
- </t>
- </list>
+ This section defines the syntax and semantics of all standard
+ HTTP/1.1 header fields. For entity-header fields, both sender and
+ recipient refer to either the client or the server, depending on who
+ sends and who receives the entity.
</t>
+<section title="Accept-Ranges" anchor="header.accept-ranges">
+ <iref primary="true" item="Accept-Ranges header" x:for-anchor=""/>
+ <iref primary="true" item="Headers" subitem="Accept-Ranges" x:for-anchor=""/>
<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>
+ The Accept-Ranges response-header field allows the server to
+ indicate its acceptance of range requests for a resource:
</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Ranges"/><iref primary="true" item="Grammar" subitem="acceptable-ranges"/>
+ Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
+ acceptable-ranges = 1#range-unit | "none"
+</artwork></figure>
<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>
+ Origin servers that accept byte-range requests &MAY; send
</t>
+<figure><artwork type="example">
+ Accept-Ranges: bytes
+</artwork></figure>
<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>
+ but are not required to do so. Clients &MAY; generate byte-range
+ requests without having received this header for the resource
+ involved. Range units are defined in <xref target="range.units"/>.
</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>
+ Servers that do not accept any kind of range request for a
+ resource &MAY; send
</t>
+<figure><artwork type="example">
+ Accept-Ranges: none
+</artwork></figure>
<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>
+ to advise the client not to attempt a range request.
</t>
+</section>
+
+<section title="Content-Range" anchor="header.content-range">
+ <iref primary="true" item="Content-Range header" x:for-anchor=""/>
+ <iref primary="true" item="Headers" subitem="Content-Range" x:for-anchor=""/>
<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>
+ The Content-Range entity-header is sent with a partial entity-body to
+ specify where in the full entity-body the partial body should be
+ applied. Range units are defined in <xref target="range.units"/>.
</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Range"/><iref primary="true" item="Grammar" subitem="content-range-spec"/><iref primary="true" item="Grammar" subitem="byte-content-range-spec"/><iref primary="true" item="Grammar" subitem="byte-range-resp-spec"/><iref primary="true" item="Grammar" subitem="instance-length"/>
+ Content-Range = "Content-Range" ":" content-range-spec
+
+ content-range-spec = byte-content-range-spec
+ byte-content-range-spec = bytes-unit SP
+ byte-range-resp-spec "/"
+ ( instance-length | "*" )
+
+ byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
+ | "*"
+ instance-length = 1*DIGIT
+</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 header &SHOULD; indicate the total length of the full entity-body,
+ unless this length is unknown or difficult to determine. The asterisk
+ "*" character means that the instance-length is unknown at the time
+ when the response was generated.
</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>
+ Unlike byte-ranges-specifier values (see <xref target="byte.ranges"/>), a byte-range-resp-spec
+ &MUST; only specify one range, and &MUST; contain
+ absolute byte positions for both the first and last byte of the
+ range.
</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>
+ A byte-content-range-spec with a byte-range-resp-spec whose last-byte-pos
+ value is less than its first-byte-pos value, or whose
+ instance-length value is less than or equal to its last-byte-pos
+ value, is invalid. The recipient of an invalid byte-content-range-spec
+ &MUST; ignore it and any content transferred along with it.
</t>
<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>
+ A server sending a response with status code 416 (Requested range not
+ satisfiable) &SHOULD; include a Content-Range field with a byte-range-resp-spec
+ of "*". The instance-length specifies the current length of
+ the selected resource. A response with status code 206 (Partial
+ Content) &MUST-NOT; include a Content-Range field with a byte-range-resp-spec of "*".
</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>
+ Examples of byte-content-range-spec values, assuming that the entity
+ contains a total of 1234 bytes:
+ <list style="symbols">
+ <t>
+ The first 500 bytes:
+<figure><artwork type="text/plain">
+ bytes 0-499/1234
+</artwork></figure>
+ </t>
+ <t>
+ The second 500 bytes:
+<figure><artwork type="text/plain">
+ bytes 500-999/1234
+</artwork></figure>
+ </t>
+ <t>
+ All except for the first 500 bytes:
+<figure><artwork type="text/plain">
+ bytes 500-1233/1234
+</artwork></figure>
+ </t>
+ <t>
+ The last 500 bytes:
+<figure><artwork type="text/plain">
+ bytes 734-1233/1234
+</artwork></figure>
+ </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>
+ When an HTTP message includes the content of a single range (for
+ example, a response to a request for a single range, or to a request
+ for a set of ranges that overlap without any holes), this content is
+ transmitted with a Content-Range header, and a Content-Length header
+ showing the number of bytes actually transferred. For example,
</t>
+<figure><artwork type="example">
+ HTTP/1.1 206 Partial content
+ Date: Wed, 15 Nov 1995 06:25:24 GMT
+ Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
+ Content-Range: bytes 21010-47021/47022
+ Content-Length: 26012
+ Content-Type: image/gif
+</artwork></figure>
<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>
+ When an HTTP message includes the content of multiple ranges (for
+ example, a response to a request for multiple non-overlapping
+ ranges), these are transmitted as a multipart message. The multipart
+ media type used for this purpose is "multipart/byteranges" as defined
+ in <xref target="internet.media.type.multipart.byteranges"/>. See <xref target="changes.from.rfc.2068"/> for a compatibility issue.
</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>
+ A response to a request for a single range &MUST-NOT; be sent using the
+ multipart/byteranges media type. A response to a request for
+ multiple ranges, whose result is a single range, &MAY; be sent as a
+ multipart/byteranges media type with one part. A client that cannot
+ decode a multipart/byteranges message &MUST-NOT; ask for multiple
+ byte-ranges in a single request.
</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>
+ When a client requests multiple byte-ranges in one request, the
+ server &SHOULD; return them in the order that they appeared in the
+ request.
</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>
+ If the server ignores a byte-range-spec because it is syntactically
+ invalid, the server &SHOULD; treat the request as if the invalid Range
+ header field did not exist. (Normally, this means return a 200
+ response containing the full entity).
+</t>
+<t>
+ If the server receives a request (other than one including an If-Range
+ request-header field) with an unsatisfiable Range request-header
+ field (that is, all of whose byte-range-spec values have a
+ first-byte-pos value greater than the current length of the selected
+ resource), it &SHOULD; return a response code of 416 (Requested range
+ not satisfiable) (<xref target="status.416"/>).
+ <list><t>
+ <x:h>Note:</x:h> clients cannot depend on servers to send a 416 (Requested
+ range not satisfiable) response instead of a 200 (OK) response for
+ an unsatisfiable Range request-header, since not all servers
+ implement this request-header.
+ </t></list>
</t>
</section>
-<section title="Overall Operation">
+<section title="If-Range" anchor="header.if-range">
+ <iref primary="true" item="If-Range header" x:for-anchor=""/>
+ <iref primary="true" item="Headers" subitem="If-Range" x:for-anchor=""/>
<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>
+ If a client has a partial copy of an entity in its cache, and wishes
+ to have an up-to-date copy of the entire entity in its cache, it
+ could use the Range request-header with a conditional GET (using
+ either or both of If-Unmodified-Since and If-Match.) However, if the
+ condition fails because the entity has been modified, the client
+ would then have to make a second request to obtain the entire current
+ entity-body.
+</t>
<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
+ The If-Range header allows a client to "short-circuit" the second
+ request. Informally, its meaning is `if the entity is unchanged, send
+ me the part(s) that I am missing; otherwise, send me the entire new
+ entity'.
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Range"/>
+ If-Range = "If-Range" ":" ( entity-tag | HTTP-date )
</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>
+ If the client has no entity tag for an entity, but does have a Last-Modified
+ date, it &MAY; use that date in an If-Range header. (The
+ server can distinguish between a valid HTTP-date and any form of
+ entity-tag by examining no more than two characters.) The If-Range
+ header &SHOULD; only be used together with a Range header, and &MUST; be
+ ignored if the request does not include a Range header, or if the
+ server does not support the sub-range operation.
+</t>
<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"/>).
+ If the entity tag given in the If-Range header matches the current
+ entity tag for the entity, then the server &SHOULD; provide the
+ specified sub-range of the entity using a 206 (Partial content)
+ response. If the entity tag does not match, then the server &SHOULD;
+ return the entire entity using a 200 (OK) response.
</t>
</section>
-</section>
-<section title="Notational Conventions and Generic Grammar">
+<section title="Range" anchor="header.range">
+ <iref primary="true" item="Range header" x:for-anchor=""/>
+ <iref primary="true" item="Headers" subitem="Range" x:for-anchor=""/>
-<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>
+<section title="Byte Ranges" anchor="byte.ranges">
<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>
+ Since all HTTP entities are represented in HTTP messages as sequences
+ of bytes, the concept of a byte range is meaningful for any HTTP
+ entity. (However, not all clients and servers need to support byte-range
+ operations.)
</t>
<t>
- "literal"
- <list>
- <t>
- Quotation marks surround literal text. Unless stated otherwise,
- the text is case-insensitive.
- </t>
- </list>
+ Byte range specifications in HTTP apply to the sequence of bytes in
+ the entity-body (not necessarily the same as the message-body).
</t>
<t>
- rule1 | rule2
- <list>
- <t>
- Elements separated by a bar ("|") are alternatives, e.g., "yes |
- no" will accept yes or no.
- </t>
- </list>
+ A byte range operation &MAY; specify a single range of bytes, or a set
+ of ranges within a single entity.
</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="ranges-specifier"/><iref primary="true" item="Grammar" subitem="byte-ranges-specifier"/><iref primary="true" item="Grammar" subitem="byte-range-set"/><iref primary="true" item="Grammar" subitem="byte-range-spec"/><iref primary="true" item="Grammar" subitem="first-byte-pos"/><iref primary="true" item="Grammar" subitem="last-byte-pos"/>
+ ranges-specifier = byte-ranges-specifier
+ byte-ranges-specifier = bytes-unit "=" byte-range-set
+ byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec )
+ byte-range-spec = first-byte-pos "-" [last-byte-pos]
+ first-byte-pos = 1*DIGIT
+ last-byte-pos = 1*DIGIT
+</artwork></figure>
<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>
+ The first-byte-pos value in a byte-range-spec gives the byte-offset
+ of the first byte in a range. The last-byte-pos value gives the
+ byte-offset of the last byte in the range; that is, the byte
+ positions specified are inclusive. Byte offsets start at zero.
</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>
+ If the last-byte-pos value is present, it &MUST; be greater than or
+ equal to the first-byte-pos in that byte-range-spec, or the byte-range-spec
+ is syntactically invalid. The recipient of a byte-range-set
+ that includes one or more syntactically invalid byte-range-spec
+ values &MUST; ignore the header field that includes that byte-range-set.
</t>
<t>
- [rule]
- <list>
- <t>
- Square brackets enclose optional elements; "[foo bar]" is
- equivalent to "*1(foo bar)".
- </t>
- </list>
+ If the last-byte-pos value is absent, or if the value is greater than
+ or equal to the current length of the entity-body, last-byte-pos is
+ taken to be equal to one less than the current length of the entity-body
+ in bytes.
</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>
+ By its choice of last-byte-pos, a client can limit the number of
+ bytes retrieved without knowing the size of the entity.
</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="suffix-byte-range-spec"/><iref primary="true" item="Grammar" subitem="suffix-length"/>
+ suffix-byte-range-spec = "-" suffix-length
+ suffix-length = 1*DIGIT
+</artwork></figure>
<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>
+ A suffix-byte-range-spec is used to specify the suffix of the
+ entity-body, of a length given by the suffix-length value. (That is,
+ this form specifies the last N bytes of an entity-body.) If the
+ entity is shorter than the specified suffix-length, the entire
+ entity-body is used.
</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>
+ If a syntactically valid byte-range-set includes at least one byte-range-spec
+ whose first-byte-pos is less than the current length of
+ the entity-body, or at least one suffix-byte-range-spec with a non-zero
+ suffix-length, then the byte-range-set is satisfiable.
+ Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set
+ is unsatisfiable, the server &SHOULD; return a response with a status
+ of 416 (Requested range not satisfiable). Otherwise, the server
+ &SHOULD; return a response with a status of 206 (Partial Content)
+ containing the satisfiable ranges of the entity-body.
</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>
+ Examples of byte-ranges-specifier values (assuming an entity-body of
+ length 10000):
+ <list style="symbols">
+ <t>The first 500 bytes (byte offsets 0-499, inclusive): bytes=0-499</t>
+
+ <t>The second 500 bytes (byte offsets 500-999, inclusive):
+ bytes=500-999</t>
+
+ <t>The final 500 bytes (byte offsets 9500-9999, inclusive):
+ bytes=-500</t>
+
+ <t>Or bytes=9500-</t>
+
+ <t>The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1</t>
+
+ <t>Several legal but not canonical specifications of the second 500
+ bytes (byte offsets 500-999, inclusive):
+ <vspace/>
+ bytes=500-600,601-999<vspace/>
+ bytes=500-700,601-999</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>
+<section title="Range Retrieval Requests">
<t>
- Hexadecimal numeric characters are used in several protocol elements.
+ HTTP retrieval requests using conditional or unconditional GET
+ methods &MAY; request one or more sub-ranges of the entity, instead of
+ the entire entity, using the Range request header, which applies to
+ the entity returned as the result of the request:
</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 ")">
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Range"/>
+ Range = "Range" ":" ranges-specifier
</artwork></figure>
<t>
- A string of text is parsed as a single word if it is quoted using
- double-quote marks.
+ A server &MAY; ignore the Range header. However, HTTP/1.1 origin
+ servers and intermediate caches ought to support byte ranges when
+ possible, since Range supports efficient recovery from partially
+ failed transfers, and supports efficient partial retrieval of large
+ entities.
</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">
+ If the server supports the Range header and the specified range or
+ ranges are appropriate for the entity:
+ <list style="symbols">
+ <t>The presence of a Range header in an unconditional GET modifies
+ what is returned if the GET is otherwise successful. In other
+ words, the response carries a status code of 206 (Partial
+ Content) instead of 200 (OK).</t>
-<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>The presence of a Range header in a conditional GET (a request
+ using one or both of If-Modified-Since and If-None-Match, or
+ one or both of If-Unmodified-Since and If-Match) modifies what
+ is returned if the GET is otherwise successful and the
+ condition is true. It does not affect the 304 (Not Modified)
+ response returned if the conditional is false.</t>
+ </list>
</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
[... 9705 lines stripped ...]
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@labs.apache.org
For additional commands, e-mail: commits-help@labs.apache.org