One document matched: draft-fielding-http-p5-range-00.xml
<?xml version="1.0" encoding="utf-8"?>
<!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 messaging "[Part 1]">
<!ENTITY weak-and-strong-validators "[Part 4]">
]>
<?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, 2617" category="std"
ipr="full3978" 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">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="James Gettys">
<organization abbrev="HP">Hewlett-Packard Company</organization>
<address>
<postal>
<street>HP Labs, Cambridge Research Laboratory</street>
<street>One Cambridge Center</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>USA</country>
</postal>
<email>Jim.Gettys@hp.com</email>
</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 Laboratory for Computer Science</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>USA</country>
</postal>
<facsimile>+1 (617) 258 8682</facsimile>
<email>timbl@w3.org</email>
</address>
</author>
<date month="November" year="2007"/>
<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 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" 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>
<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="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" format="counter"/>.
</t>
<t>
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>
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 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 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>
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>
<t>
Based on an XML translation of RFC 2616 by Julian Reschke.
</t>
</section>
</middle>
<back>
<references>
<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>
<postal>
<street>1050 East Garvey Avenue South</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country></postal>
<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email></address></author>
<author initials="N." surname="Borenstein" fullname="Nathaniel S. Borenstein">
<organization>First Virtual Holdings</organization>
<address>
<postal>
<street>25 Washington Avenue</street>
<city>Morristown</city>
<region>NJ</region>
<code>07960</code>
<country>US</country></postal>
<phone>+1 201 540 8967</phone>
<facsimile>+1 201 993 3032</facsimile>
<email>nsb@nsb.fv.com</email></address></author>
<date month="November" year="1996"/>
</front>
<seriesInfo name="RFC" value="2046"/>
</reference>
<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 RFC 2046 <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="Changes from RFC 2068" anchor="changes.from.rfc.2068">
<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.
</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>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:23:41 |