source: draft-ietf-httpbis/latest/p5-range.xml @ 144

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type='text/xsl' href='../myxml2rfc.xslt'?>
<!DOCTYPE rfc [
  <!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>">
  <!ENTITY MUST "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST</bcp14>">
  <!ENTITY MUST-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST NOT</bcp14>">
  <!ENTITY OPTIONAL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>OPTIONAL</bcp14>">
  <!ENTITY RECOMMENDED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>RECOMMENDED</bcp14>">
  <!ENTITY REQUIRED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>REQUIRED</bcp14>">
  <!ENTITY SHALL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL</bcp14>">
  <!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 ID-VERSION "latest">
  <!ENTITY ID-MONTH "January">
  <!ENTITY ID-YEAR "2008">
  <!ENTITY messaging                  "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
  <!ENTITY weak-and-strong-validators "<xref target='Part4' x:rel='#weak.and.strong.validators' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
]>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no" ?>
<?rfc linkmailto="no" ?>
<?rfc editing="no" ?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext include-references-in-index="yes" ?>
<rfc obsoletes="2068, 2616" category="std"
     ipr="full3978" docName="draft-ietf-httpbis-p5-range-&ID-VERSION;"
     xmlns:x='http://purl.org/net/xml2rfc/ext' xmlns:ed="http://greenbytes.de/2002/rfcedit">
<front>

  <title abbrev="HTTP/1.1, Part 5">HTTP/1.1, part 5: Range Requests and Partial Responses</title>

  <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
    <organization abbrev="Day Software">Day Software</organization>
    <address>
      <postal>
        <street>23 Corporate Plaza DR, Suite 280</street>
        <city>Newport Beach</city>
        <region>CA</region>
        <code>92660</code>
        <country>USA</country>
      </postal>
      <phone>+1-949-706-5300</phone>
      <facsimile>+1-949-706-5305</facsimile>
      <email>fielding@gbiv.com</email>
      <uri>http://roy.gbiv.com/</uri>
    </address>
  </author>

  <author initials="J." surname="Gettys" fullname="Jim Gettys">
    <organization>One Laptop per Child</organization>
    <address>
      <postal>
        <street>21 Oak Knoll Road</street>
        <city>Carlisle</city>
        <region>MA</region>
        <code>01741</code>
        <country>USA</country>
      </postal>
      <email>jg@laptop.org</email>
      <uri>http://www.laptop.org/</uri>
    </address>
  </author>
  
  <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
    <organization abbrev="HP">Hewlett-Packard Company</organization>
    <address>
      <postal>
        <street>HP Labs, Large Scale Systems Group</street>
        <street>1501 Page Mill Road, MS 1177</street>
        <city>Palo Alto</city>
        <region>CA</region>
        <code>94304</code>
        <country>USA</country>
      </postal>
      <email>JeffMogul@acm.org</email>
    </address>
  </author>

  <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
    <organization abbrev="Microsoft">Microsoft Corporation</organization>
    <address>
      <postal>
        <street>1 Microsoft Way</street>
        <city>Redmond</city>
        <region>WA</region>
        <code>98052</code>
        <country>USA</country>
      </postal>
      <email>henrikn@microsoft.com</email>
    </address>
  </author>

  <author initials="L." surname="Masinter" fullname="Larry Masinter">
    <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
    <address>
      <postal>
        <street>345 Park Ave</street>
        <city>San Jose</city>
        <region>CA</region>
        <code>95110</code>
        <country>USA</country>
      </postal>
      <email>LMM@acm.org</email>
      <uri>http://larry.masinter.net/</uri>
    </address>
  </author>
  
  <author initials="P." surname="Leach" fullname="Paul J. Leach">
    <organization abbrev="Microsoft">Microsoft Corporation</organization>
    <address>
      <postal>
        <street>1 Microsoft Way</street>
        <city>Redmond</city>
        <region>WA</region>
        <code>98052</code>
      </postal>
      <email>paulle@microsoft.com</email>
    </address>
  </author>
   
  <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
    <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
    <address>
      <postal>
        <street>MIT Computer Science and Artificial Intelligence Laboratory</street>
        <street>The Stata Center, Building 32</street>
        <street>32 Vassar Street</street>
        <city>Cambridge</city>
        <region>MA</region>
        <code>02139</code>
        <country>USA</country>
      </postal>
      <email>timbl@w3.org</email>
      <uri>http://www.w3.org/People/Berners-Lee/</uri>
    </address>
  </author>

  <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
    <organization abbrev="W3C">World Wide Web Consortium</organization>
    <address>
      <postal>
        <street>W3C / ERCIM</street>
        <street>2004, rte des Lucioles</street>
        <city>Sophia-Antipolis</city>
        <region>AM</region>
        <code>06902</code>
        <country>France</country>
      </postal>
      <email>ylafon@w3.org</email>
      <uri>http://www.raubacapeu.net/people/yves/</uri>
    </address>
  </author>

  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
    <organization abbrev="greenbytes">greenbytes GmbH</organization>
    <address>
      <postal>
        <street>Hafenweg 16</street>
        <city>Muenster</city><region>NW</region><code>48155</code>
        <country>Germany</country>
      </postal>
      <phone>+49 251 2807760</phone>    
      <facsimile>+49 251 2807761</facsimile>    
      <email>julian.reschke@greenbytes.de</email>       
      <uri>http://greenbytes.de/tech/webdav/</uri>      
    </address>
  </author>

  <date month="&ID-MONTH;" year="&ID-YEAR;"/>

<abstract>
<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. This document is Part 5 of the seven-part specification
   that defines the protocol referred to as "HTTP/1.1" and, taken together,
   obsoletes RFC 2616.  Part 5 defines range-specific requests and
   the rules for constructing and combining responses to those requests.
</t>
</abstract>

<note title="Editorial Note (To be removed by RFC Editor)">
  <t>
    Discussion of this draft should take place on the HTTPBIS working group
    mailing list (ietf-http-wg@w3.org). The current issues list is
    at <eref target="http://www.tools.ietf.org/wg/httpbis/trac/report/11"/>
    and related documents (including fancy diffs) can be found at
    <eref target="http://www.tools.ietf.org/wg/httpbis/"/>.
  </t>
</note>
</front>
<middle>
<section title="Introduction" anchor="introduction">
<t>
   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 title="Requirements" anchor="intro.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 <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>

<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 title="Status Code Definitions">
<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>
   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>
   The response &MUST; include the following header fields:
  <list style="symbols">
    <t>
        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>
    <t>
        Date
    </t>
    <t>
        ETag and/or Content-Location, if the header would have been sent
        in a 200 response to the same request
    </t>
    <t>
        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>
   If the 206 response is the result of an If-Range request, the response
   &SHOULD-NOT; include other entity-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>
   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"/>.
</t>
<t>
   A cache that does not support the Range and Content-Range headers
   &MUST-NOT; cache 206 (Partial Content) 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>
   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>
   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>

<section title="Combining Byte Ranges" anchor="combining.byte.ranges">
<t>
   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>
   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>
   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" anchor="header.fields">
<t>
   This section defines the syntax and semantics of HTTP/1.1 header fields
   related to range requests and partial responses.
</t>
<t>
   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>
      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>
      Origin servers that accept byte-range requests &MAY; send
</t>
<figure><artwork type="example">
       Accept-Ranges: bytes
</artwork></figure>
<t>
      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>
      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>
      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>
   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>
   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>
   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>
   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>
   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>
   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>
   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>
   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>
   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>
   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>
   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="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>
   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>
   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>
   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>
   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 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="Byte Ranges" anchor="byte.ranges">
<t>
   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>
   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>
   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>
   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>
   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>
   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>
   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>
   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>
   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>
   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="Range Retrieval Requests" anchor="range.retrieval.requests">
<t>
   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="Range"/>
  Range = "Range" ":" ranges-specifier
</artwork></figure>
<t>
   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>
<t>
   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>

     <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>
<t>
   In some cases, it might be more appropriate to use the If-Range
   header (see <xref target="header.if-range"/>) in addition to the Range header.
</t>
<t>
   If a proxy that supports ranges receives a Range request, forwards
   the request to an inbound server, and receives an entire entity in
   reply, it &SHOULD; only return the requested range to its client. It
   &SHOULD; store the entire received response in its cache if that is
   consistent with its cache allocation policies.
</t>
</section>
</section>
</section>

<section title="IANA Considerations" anchor="IANA.considerations">
<t>
   TBD.
</t>
</section>

<section title="Security Considerations" anchor="security.considerations">
<t>
   No additional security considerations have been identified beyond
   those applicable to HTTP in general &messaging;.
</t>
</section>

<section title="Acknowledgments" anchor="ack">
<t>
   Most of the specification of ranges is based on work originally done
   by Ari Luotonen and John Franks, with additional input from Steve
   Zilles.
</t>
</section>
</middle>
<back>

<references title="Normative References">

<reference anchor="Part1">
  <front>
    <title abbrev="HTTP/1.1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title>
    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
      <organization abbrev="Day Software">Day Software</organization>
      <address><email>fielding@gbiv.com</email></address>
    </author>
    <author initials="J." surname="Gettys" fullname="Jim Gettys">
      <organization>One Laptop per Child</organization>
      <address><email>jg@laptop.org</email></address>
    </author>
    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
      <organization abbrev="HP">Hewlett-Packard Company</organization>
      <address><email>JeffMogul@acm.org</email></address>
    </author>
    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
      <organization abbrev="Microsoft">Microsoft Corporation</organization>
      <address><email>henrikn@microsoft.com</email></address>
    </author>
    <author initials="L." surname="Masinter" fullname="Larry Masinter">
      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
      <address><email>LMM@acm.org</email></address>
    </author>
    <author initials="P." surname="Leach" fullname="Paul J. Leach">
      <organization abbrev="Microsoft">Microsoft Corporation</organization>
      <address><email>paulle@microsoft.com</email></address>
    </author>
    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
      <address><email>timbl@w3.org</email></address>
    </author>
    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
      <organization abbrev="W3C">World Wide Web Consortium</organization>
      <address><email>ylafon@w3.org</email></address>
    </author>
    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
      <organization abbrev="greenbytes">greenbytes GmbH</organization>
      <address><email>julian.reschke@greenbytes.de</email></address>
    </author>
    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"/>
  <x:source href="p1-messaging.xml" basename="p1-messaging"/>
</reference>

<reference anchor="Part3">
  <front>
    <title abbrev="HTTP/1.1">HTTP/1.1, part 3: Message Payload and Content Negotiation</title>
    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
      <organization abbrev="Day Software">Day Software</organization>
      <address><email>fielding@gbiv.com</email></address>
    </author>
    <author initials="J." surname="Gettys" fullname="Jim Gettys">
      <organization>One Laptop per Child</organization>
      <address><email>jg@laptop.org</email></address>
    </author>
    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
      <organization abbrev="HP">Hewlett-Packard Company</organization>
      <address><email>JeffMogul@acm.org</email></address>
    </author>
    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
      <organization abbrev="Microsoft">Microsoft Corporation</organization>
      <address><email>henrikn@microsoft.com</email></address>
    </author>
    <author initials="L." surname="Masinter" fullname="Larry Masinter">
      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
      <address><email>LMM@acm.org</email></address>
    </author>
    <author initials="P." surname="Leach" fullname="Paul J. Leach">
      <organization abbrev="Microsoft">Microsoft Corporation</organization>
      <address><email>paulle@microsoft.com</email></address>
    </author>
    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
      <address><email>timbl@w3.org</email></address>
    </author>
    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
      <organization abbrev="W3C">World Wide Web Consortium</organization>
      <address><email>ylafon@w3.org</email></address>
    </author>
    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
      <organization abbrev="greenbytes">greenbytes GmbH</organization>
      <address><email>julian.reschke@greenbytes.de</email></address>
    </author>
    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p3-payload-&ID-VERSION;"/>
  <x:source href="p3-payload.xml" basename="p3-payload"/>
</reference>

<reference anchor="Part4">
  <front>
    <title abbrev="HTTP/1.1">HTTP/1.1, part 4: Conditional Requests</title>
    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
      <organization abbrev="Day Software">Day Software</organization>
      <address><email>fielding@gbiv.com</email></address>
    </author>
    <author initials="J." surname="Gettys" fullname="Jim Gettys">
      <organization>One Laptop per Child</organization>
      <address><email>jg@laptop.org</email></address>
    </author>
    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
      <organization abbrev="HP">Hewlett-Packard Company</organization>
      <address><email>JeffMogul@acm.org</email></address>
    </author>
    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
      <organization abbrev="Microsoft">Microsoft Corporation</organization>
      <address><email>henrikn@microsoft.com</email></address>
    </author>
    <author initials="L." surname="Masinter" fullname="Larry Masinter">
      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
      <address><email>LMM@acm.org</email></address>
    </author>
    <author initials="P." surname="Leach" fullname="Paul J. Leach">
      <organization abbrev="Microsoft">Microsoft Corporation</organization>
      <address><email>paulle@microsoft.com</email></address>
    </author>
    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
      <address><email>timbl@w3.org</email></address>
    </author>
    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
      <organization abbrev="W3C">World Wide Web Consortium</organization>
      <address><email>ylafon@w3.org</email></address>
    </author>
    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
      <organization abbrev="greenbytes">greenbytes GmbH</organization>
      <address><email>julian.reschke@greenbytes.de</email></address>
    </author>
    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p4-conditional-&ID-VERSION;"/>
  <x:source href="p4-conditional.xml" basename="p4-conditional"/>
</reference>

<reference anchor="Part6">
  <front>
    <title abbrev="HTTP/1.1">HTTP/1.1, part 6: Caching</title>
    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
      <organization abbrev="Day Software">Day Software</organization>
      <address><email>fielding@gbiv.com</email></address>
    </author>
    <author initials="J." surname="Gettys" fullname="Jim Gettys">
      <organization>One Laptop per Child</organization>
      <address><email>jg@laptop.org</email></address>
    </author>
    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
      <organization abbrev="HP">Hewlett-Packard Company</organization>
      <address><email>JeffMogul@acm.org</email></address>
    </author>
    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
      <organization abbrev="Microsoft">Microsoft Corporation</organization>
      <address><email>henrikn@microsoft.com</email></address>
    </author>
    <author initials="L." surname="Masinter" fullname="Larry Masinter">
      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
      <address><email>LMM@acm.org</email></address>
    </author>
    <author initials="P." surname="Leach" fullname="Paul J. Leach">
      <organization abbrev="Microsoft">Microsoft Corporation</organization>
      <address><email>paulle@microsoft.com</email></address>
    </author>
    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
      <address><email>timbl@w3.org</email></address>
    </author>
    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
      <organization abbrev="W3C">World Wide Web Consortium</organization>
      <address><email>ylafon@w3.org</email></address>
    </author>
    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
      <organization abbrev="greenbytes">greenbytes GmbH</organization>
      <address><email>julian.reschke@greenbytes.de</email></address>
    </author>
    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/>
  <x:source href="p6-cache.xml" basename="p6-cache"/>
</reference>

<reference anchor="RFC2046">
  <front>
    <title abbrev="Media Types">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title>
    <author initials="N." surname="Freed" fullname="Ned Freed">
      <organization>Innosoft International, Inc.</organization>
      <address><email>ned@innosoft.com</email></address>
    </author>
    <author initials="N." surname="Borenstein" fullname="Nathaniel S. Borenstein">
      <organization>First Virtual Holdings</organization>
      <address><email>nsb@nsb.fv.com</email></address>
    </author>
    <date month="November" year="1996"/>
  </front>
  <seriesInfo name="RFC" value="2046"/>
</reference>

<reference anchor="RFC2119">
  <front>
    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
    <author initials="S." surname="Bradner" fullname="Scott Bradner">
      <organization>Harvard University</organization>
      <address><email>sob@harvard.edu</email></address>
    </author>
    <date month="March" year="1997"/>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="2119"/>
</reference>

</references>

<references title="Informative References">

<reference anchor="RFC2616">
  <front>
    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
    <author initials="R." surname="Fielding" fullname="R. Fielding">
      <organization>University of California, Irvine</organization>
      <address><email>fielding@ics.uci.edu</email></address>
    </author>
    <author initials="J." surname="Gettys" fullname="J. Gettys">
      <organization>W3C</organization>
      <address><email>jg@w3.org</email></address>
    </author>
    <author initials="J." surname="Mogul" fullname="J. Mogul">
      <organization>Compaq Computer Corporation</organization>
      <address><email>mogul@wrl.dec.com</email></address>
    </author>
    <author initials="H." surname="Frystyk" fullname="H. Frystyk">
      <organization>MIT Laboratory for Computer Science</organization>
      <address><email>frystyk@w3.org</email></address>
    </author>
    <author initials="L." surname="Masinter" fullname="L. Masinter">
      <organization>Xerox Corporation</organization>
      <address><email>masinter@parc.xerox.com</email></address>
    </author>
    <author initials="P." surname="Leach" fullname="P. Leach">
      <organization>Microsoft Corporation</organization>
      <address><email>paulle@microsoft.com</email></address>
    </author>
    <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
      <organization>W3C</organization>
      <address><email>timbl@w3.org</email></address>
    </author>
    <date month="June" year="1999"/>
  </front>
  <seriesInfo name="RFC" value="2616"/>
</reference>

</references>

<section title="Internet Media Type multipart/byteranges" anchor="internet.media.type.multipart.byteranges">
<iref item="Media Type" subitem="multipart/byteranges" primary="true"/>
<iref item="multipart/byteranges Media Type" primary="true"/>
<t>
   When an HTTP 206 (Partial Content) response message includes the
   content of multiple ranges (a response to a request for multiple
   non-overlapping ranges), these are transmitted as a multipart
   message-body. The media type for this purpose is called
   "multipart/byteranges".
</t><t>
   The multipart/byteranges media type includes two or more parts, each
   with its own Content-Type and Content-Range fields. The required
   boundary parameter specifies the boundary string used to separate
   each body-part.
</t>
<t>
  <list style="hanging" x:indent="12em">
    <t hangText="Media Type name:">
      multipart
    </t>
    <t hangText="Media subtype name:">
      byteranges
    </t>
    <t hangText="Required parameters:">
      boundary
    </t>
    <t hangText="Optional parameters:">
      none
    </t>
    <t hangText="Encoding considerations:">
      only "7bit", "8bit", or "binary" are permitted
    </t>
    <t hangText="Security considerations:">
      none
    </t>
  </list>
</t>
<figure><preamble>
   For example:
</preamble><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-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

   --THIS_STRING_SEPARATES
   Content-type: application/pdf
   Content-range: bytes 500-999/8000

   ...the first range...
   --THIS_STRING_SEPARATES
   Content-type: application/pdf
   Content-range: bytes 7000-7999/8000

   ...the second range
   --THIS_STRING_SEPARATES--
</artwork></figure>
<t>
      Notes:
  <list style="numbers">
      <t>Additional CRLFs may precede the first boundary string in the
         entity.</t>

      <t>Although <xref target="RFC2046"/> permits the boundary string to be
         quoted, some existing implementations handle a quoted boundary
         string incorrectly.</t>

      <t>A number of browsers and servers were coded to an early draft
         of the byteranges specification to use a media type of
         multipart/x-byteranges<iref item="multipart/x-byteranges Media Type"/><iref item="Media Type" subitem="multipart/x-byteranges"/>, which is almost, but not quite
         compatible with the version documented in HTTP/1.1.</t>
  </list>
</t>
</section>

<section title="Compatibility with Previous Versions" anchor="compatibility">
<section title="Changes from RFC 2068" anchor="changes.from.rfc.2068">
<t>
   Transfer-coding and message lengths all interact in ways that
   required fixing exactly when chunked encoding is used (to allow for
   transfer encoding that may not be self delimiting); it was important
   to straighten out exactly how message lengths are computed.
   (<xref target="header.content-range"/>,
   see also <xref target="Part1"/>, <xref target="Part3"/> and <xref target="Part6"/>)
</t>
<t>
   There are situations where a server (especially a proxy) does not
   know the full length of a response but is capable of serving a
   byterange request. We therefore need a mechanism to allow byteranges
   with a content-range not indicating the full length of the message.
   (<xref target="header.content-range"/>)
</t>
<t>
   Range request responses would become very verbose if all meta-data
   were always returned; by allowing the server to only send needed
   headers in a 206 response, this problem can be avoided.
   (Section <xref target="status.206" format="counter"/>
   and <xref target="header.if-range" format="counter"/>)
</t>
<t>
   Fix problem with unsatisfiable range requests; there are two cases:
   syntactic problems, and range doesn't exist in the document. The 416
   status code was needed to resolve this ambiguity needed to indicate
   an error for a byte range request that falls outside of the actual
   contents of a document. (Section <xref target="status.416" format="counter"/>, <xref target="header.content-range" format="counter"/>)
</t>
</section>

<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
<t>
  Clarify that it is not ok to use a weak cache validator in a 206 response.
  (<xref target="status.206"/>)
</t>
</section>

</section>

<section title="Change Log (to be removed by RFC Editor before publication)">

<section title="Since RFC2616">
<t>
  Extracted relevant partitions from <xref target="RFC2616"/>.
</t>
</section>

<section title="Since draft-ietf-httpbis-p5-range-00">
<t>
  Closed issues:
  <list style="symbols"> 
    <t>
      <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/18"/>:
      "Cache validators in 206 responses"
      (<eref target="http://purl.org/NET/http-errata#ifrange206"/>)
    </t>
    <t>
      <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/86"/>:
      "Normative up-to-date references"
    </t>
  </list>
</t>
<t>
  Other changes:
  <list style="symbols">
    <t>
      Categorize references as "Normative" or "Informative".
    </t>
  </list>
</t>
</section>

</section>

</back>
</rfc>