1 | <?xml version="1.0" encoding="utf-8"?> |
---|
2 | <?xml-stylesheet type='text/xsl' href='../myxml2rfc.xslt'?> |
---|
3 | <!DOCTYPE rfc [ |
---|
4 | <!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>"> |
---|
5 | <!ENTITY MUST "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST</bcp14>"> |
---|
6 | <!ENTITY MUST-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST NOT</bcp14>"> |
---|
7 | <!ENTITY OPTIONAL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>OPTIONAL</bcp14>"> |
---|
8 | <!ENTITY RECOMMENDED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>RECOMMENDED</bcp14>"> |
---|
9 | <!ENTITY REQUIRED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>REQUIRED</bcp14>"> |
---|
10 | <!ENTITY SHALL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL</bcp14>"> |
---|
11 | <!ENTITY SHALL-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL NOT</bcp14>"> |
---|
12 | <!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>"> |
---|
13 | <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>"> |
---|
14 | <!ENTITY ID-VERSION "latest"> |
---|
15 | <!ENTITY ID-MONTH "July"> |
---|
16 | <!ENTITY ID-YEAR "2012"> |
---|
17 | <!ENTITY Note "<x:h xmlns:x='http://purl.org/net/xml2rfc/ext'>Note:</x:h>"> |
---|
18 | <!ENTITY architecture "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
19 | <!ENTITY notation "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
20 | <!ENTITY abnf-extension "<xref target='Part1' x:rel='#abnf.extension' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
21 | <!ENTITY acks "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
22 | <!ENTITY whitespace "<xref target='Part1' x:rel='#whitespace' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
23 | <!ENTITY field-components "<xref target='Part1' x:rel='#field.components' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
24 | <!ENTITY http-date "<xref target='Part2' x:rel='#http.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
25 | <!ENTITY messaging "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
26 | <!ENTITY entity-tags "<xref target='Part4' x:rel='#header.etag' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
27 | <!ENTITY weak-and-strong-validators "<xref target='Part4' x:rel='#weak.and.strong.validators' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
28 | <!ENTITY lastmod-comparison "<xref target='Part4' x:rel='#lastmod.comparison' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
29 | <!ENTITY p6-heuristic "<xref target='Part6' x:rel='#heuristic.freshness' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
30 | ]> |
---|
31 | <?rfc toc="yes" ?> |
---|
32 | <?rfc symrefs="yes" ?> |
---|
33 | <?rfc sortrefs="yes" ?> |
---|
34 | <?rfc compact="yes"?> |
---|
35 | <?rfc subcompact="no" ?> |
---|
36 | <?rfc linkmailto="no" ?> |
---|
37 | <?rfc editing="no" ?> |
---|
38 | <?rfc comments="yes"?> |
---|
39 | <?rfc inline="yes"?> |
---|
40 | <?rfc rfcedstyle="yes"?> |
---|
41 | <?rfc-ext allow-markup-in-artwork="yes" ?> |
---|
42 | <?rfc-ext include-references-in-index="yes" ?> |
---|
43 | <rfc obsoletes="2616" category="std" x:maturity-level="proposed" |
---|
44 | ipr="pre5378Trust200902" docName="draft-ietf-httpbis-p5-range-&ID-VERSION;" |
---|
45 | xmlns:x='http://purl.org/net/xml2rfc/ext'> |
---|
46 | <x:link rel="prev" basename="p4-conditional"/> |
---|
47 | <x:link rel="next" basename="p6-cache"/> |
---|
48 | <x:feedback template="mailto:ietf-http-wg@w3.org?subject={docname},%20%22{section}%22&body=<{ref}>:"/> |
---|
49 | <front> |
---|
50 | |
---|
51 | <title abbrev="HTTP/1.1, Part 5">HTTP/1.1, part 5: Range Requests</title> |
---|
52 | |
---|
53 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
54 | <organization abbrev="Adobe">Adobe Systems Incorporated</organization> |
---|
55 | <address> |
---|
56 | <postal> |
---|
57 | <street>345 Park Ave</street> |
---|
58 | <city>San Jose</city> |
---|
59 | <region>CA</region> |
---|
60 | <code>95110</code> |
---|
61 | <country>USA</country> |
---|
62 | </postal> |
---|
63 | <email>fielding@gbiv.com</email> |
---|
64 | <uri>http://roy.gbiv.com/</uri> |
---|
65 | </address> |
---|
66 | </author> |
---|
67 | |
---|
68 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
69 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
70 | <address> |
---|
71 | <postal> |
---|
72 | <street>W3C / ERCIM</street> |
---|
73 | <street>2004, rte des Lucioles</street> |
---|
74 | <city>Sophia-Antipolis</city> |
---|
75 | <region>AM</region> |
---|
76 | <code>06902</code> |
---|
77 | <country>France</country> |
---|
78 | </postal> |
---|
79 | <email>ylafon@w3.org</email> |
---|
80 | <uri>http://www.raubacapeu.net/people/yves/</uri> |
---|
81 | </address> |
---|
82 | </author> |
---|
83 | |
---|
84 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
85 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
86 | <address> |
---|
87 | <postal> |
---|
88 | <street>Hafenweg 16</street> |
---|
89 | <city>Muenster</city><region>NW</region><code>48155</code> |
---|
90 | <country>Germany</country> |
---|
91 | </postal> |
---|
92 | <email>julian.reschke@greenbytes.de</email> |
---|
93 | <uri>http://greenbytes.de/tech/webdav/</uri> |
---|
94 | </address> |
---|
95 | </author> |
---|
96 | |
---|
97 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
98 | <workgroup>HTTPbis Working Group</workgroup> |
---|
99 | |
---|
100 | <abstract> |
---|
101 | <t> |
---|
102 | The Hypertext Transfer Protocol (HTTP) is an application-level protocol for |
---|
103 | distributed, collaborative, hypertext information systems. HTTP has been in |
---|
104 | use by the World Wide Web global information initiative since 1990. This |
---|
105 | document is Part 5 of the seven-part specification that defines the protocol |
---|
106 | referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. |
---|
107 | </t> |
---|
108 | <t> |
---|
109 | Part 5 defines range requests and the rules for constructing and |
---|
110 | combining responses to those requests. |
---|
111 | </t> |
---|
112 | </abstract> |
---|
113 | |
---|
114 | <note title="Editorial Note (To be removed by RFC Editor)"> |
---|
115 | <t> |
---|
116 | Discussion of this draft takes place on the HTTPBIS working group |
---|
117 | mailing list (ietf-http-wg@w3.org), which is archived at |
---|
118 | <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>. |
---|
119 | </t> |
---|
120 | <t> |
---|
121 | The current issues list is at |
---|
122 | <eref target="http://tools.ietf.org/wg/httpbis/trac/report/3"/> and related |
---|
123 | documents (including fancy diffs) can be found at |
---|
124 | <eref target="http://tools.ietf.org/wg/httpbis/"/>. |
---|
125 | </t> |
---|
126 | <t> |
---|
127 | The changes in this draft are summarized in <xref target="changes.since.19"/>. |
---|
128 | </t> |
---|
129 | </note> |
---|
130 | </front> |
---|
131 | <middle> |
---|
132 | <section title="Introduction" anchor="introduction"> |
---|
133 | <t> |
---|
134 | HTTP clients often encounter interrupted data transfers as a result |
---|
135 | of canceled requests or dropped connections. When a client has stored |
---|
136 | a partial representation, it is desirable to request the remainder |
---|
137 | of that representation in a subsequent request rather than transfer |
---|
138 | the entire representation. |
---|
139 | There are also a number of Web applications that benefit from being |
---|
140 | able to request only a subset of a larger representation, such as a |
---|
141 | single page of a very large document or only part of an image to be |
---|
142 | rendered by a device with limited local storage. |
---|
143 | </t> |
---|
144 | <t> |
---|
145 | This document defines HTTP/1.1 range requests, |
---|
146 | partial responses, and the multipart/byteranges media type. |
---|
147 | The protocol for range requests is an &OPTIONAL; feature of HTTP, |
---|
148 | designed so resources or recipients that do not implement this feature |
---|
149 | can respond as if it is a normal GET request without impacting |
---|
150 | interoperability. Partial responses are indicated by a distinct status |
---|
151 | code to not be mistaken for full responses by intermediate caches |
---|
152 | that might not implement the feature. |
---|
153 | </t> |
---|
154 | <t> |
---|
155 | Although the HTTP range request mechanism is designed to allow for |
---|
156 | extensible range types, this specification only defines requests for |
---|
157 | byte ranges. |
---|
158 | </t> |
---|
159 | |
---|
160 | <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling"> |
---|
161 | <t> |
---|
162 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
---|
163 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
---|
164 | document are to be interpreted as described in <xref target="RFC2119"/>. |
---|
165 | </t> |
---|
166 | <t> |
---|
167 | This specification targets conformance criteria according to the role of |
---|
168 | a participant in HTTP communication. Hence, HTTP requirements are placed |
---|
169 | on senders, recipients, clients, servers, user agents, intermediaries, |
---|
170 | origin servers, proxies, gateways, or caches, depending on what behavior |
---|
171 | is being constrained by the requirement. See &architecture; for definitions |
---|
172 | of these terms. |
---|
173 | </t> |
---|
174 | <t> |
---|
175 | The verb "generate" is used instead of "send" where a requirement |
---|
176 | differentiates between creating a protocol element and merely forwarding a |
---|
177 | received element downstream. |
---|
178 | </t> |
---|
179 | <t> |
---|
180 | An implementation is considered conformant if it complies with all of the |
---|
181 | requirements associated with the roles it partakes in HTTP. Note that |
---|
182 | SHOULD-level requirements are relevant here, unless one of the documented |
---|
183 | exceptions is applicable. |
---|
184 | </t> |
---|
185 | <t> |
---|
186 | This document also uses ABNF to define valid protocol elements |
---|
187 | (<xref target="notation"/>). |
---|
188 | In addition to the prose requirements placed upon them, senders &MUST-NOT; |
---|
189 | generate protocol elements that do not match the grammar defined by the |
---|
190 | ABNF rules for those protocol elements that are applicable to the sender's |
---|
191 | role. If a received protocol element is processed, the recipient &MUST; be |
---|
192 | able to parse any value that would match the ABNF rules for that protocol |
---|
193 | element, excluding only those rules not applicable to the recipient's role. |
---|
194 | </t> |
---|
195 | <t> |
---|
196 | Unless noted otherwise, a recipient &MAY; attempt to recover a usable |
---|
197 | protocol element from an invalid construct. HTTP does not define |
---|
198 | specific error handling mechanisms except when they have a direct impact |
---|
199 | on security, since different applications of the protocol require |
---|
200 | different error handling strategies. For example, a Web browser might |
---|
201 | wish to transparently recover from a response where the |
---|
202 | <x:ref>Location</x:ref> header field doesn't parse according to the ABNF, |
---|
203 | whereas a systems control client might consider any form of error recovery |
---|
204 | to be dangerous. |
---|
205 | </t> |
---|
206 | </section> |
---|
207 | |
---|
208 | <section title="Syntax Notation" anchor="notation"> |
---|
209 | <t> |
---|
210 | This specification uses the Augmented Backus-Naur Form (ABNF) notation |
---|
211 | of <xref target="RFC5234"/> with the list rule extension defined in |
---|
212 | ¬ation;. <xref target="imported.abnf"/> describes rules imported from |
---|
213 | other documents. <xref target="collected.abnf"/> shows the collected ABNF |
---|
214 | with the list rule expanded. |
---|
215 | </t> |
---|
216 | </section> |
---|
217 | |
---|
218 | </section> |
---|
219 | |
---|
220 | |
---|
221 | <section title="Range Units" anchor="range.units"> |
---|
222 | <x:anchor-alias value="bytes-unit"/> |
---|
223 | <x:anchor-alias value="other-range-unit"/> |
---|
224 | <x:anchor-alias value="range-unit"/> |
---|
225 | <t> |
---|
226 | HTTP/1.1 allows a client to request that only part (a range) of the |
---|
227 | representation be included within the response. HTTP/1.1 uses range |
---|
228 | units in the <x:ref>Range</x:ref> (<xref target="header.range"/>) and |
---|
229 | <x:ref>Content-Range</x:ref> (<xref target="header.content-range"/>) |
---|
230 | header fields. A representation can be broken down into subranges according |
---|
231 | to various structural units. |
---|
232 | </t> |
---|
233 | <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"/> |
---|
234 | <x:ref>range-unit</x:ref> = <x:ref>bytes-unit</x:ref> / <x:ref>other-range-unit</x:ref> |
---|
235 | <x:ref>bytes-unit</x:ref> = "bytes" |
---|
236 | <x:ref>other-range-unit</x:ref> = <x:ref>token</x:ref> |
---|
237 | </artwork></figure> |
---|
238 | <t> |
---|
239 | HTTP/1.1 has been designed to allow implementations of applications |
---|
240 | that do not depend on knowledge of ranges. The only range unit defined |
---|
241 | by HTTP/1.1 is "bytes". Additional specifiers can be defined as described |
---|
242 | in <xref target="range.specifier.registry"/>. |
---|
243 | </t> |
---|
244 | <t> |
---|
245 | If a range unit is not understood in a request, a server &MUST; ignore |
---|
246 | the whole <x:ref>Range</x:ref> header field (<xref target="header.range"/>). |
---|
247 | If a range unit is not understood in a response, an intermediary |
---|
248 | &SHOULD; pass the response to the client; a client &MUST; fail. |
---|
249 | </t> |
---|
250 | |
---|
251 | <section title="Range Specifier Registry" anchor="range.specifier.registry"> |
---|
252 | <t> |
---|
253 | The HTTP Range Specifier Registry defines the name space for the range |
---|
254 | specifier names. |
---|
255 | </t> |
---|
256 | <t> |
---|
257 | Registrations &MUST; include the following fields: |
---|
258 | <list style="symbols"> |
---|
259 | <t>Name</t> |
---|
260 | <t>Description</t> |
---|
261 | <t>Pointer to specification text</t> |
---|
262 | </list> |
---|
263 | </t> |
---|
264 | <t> |
---|
265 | Values to be added to this name space require IETF Review |
---|
266 | (see <xref target="RFC5226" x:fmt="," x:sec="4.1"/>). |
---|
267 | </t> |
---|
268 | <t> |
---|
269 | The registry itself is maintained at |
---|
270 | <eref target="http://www.iana.org/assignments/http-range-specifiers"/>. |
---|
271 | </t> |
---|
272 | </section> |
---|
273 | |
---|
274 | </section> |
---|
275 | |
---|
276 | <section title="Status Code Definitions" anchor="status.code.definitions"> |
---|
277 | <section title="206 Partial Content" anchor="status.206"> |
---|
278 | <iref primary="true" item="206 Partial Content (status code)" x:for-anchor=""/> |
---|
279 | <iref primary="true" item="Status Codes" subitem="206 Partial Content" x:for-anchor=""/> |
---|
280 | <x:anchor-alias value="206"/> |
---|
281 | <x:anchor-alias value="206 (Partial Content)"/> |
---|
282 | <t> |
---|
283 | The server has fulfilled the partial GET request for the resource. |
---|
284 | The request &MUST; have included a <x:ref>Range</x:ref> header field |
---|
285 | (<xref target="header.range"/>) indicating the desired range, and &MAY; have |
---|
286 | included an <x:ref>If-Range</x:ref> header field |
---|
287 | (<xref target="header.if-range"/>) to make the request conditional. |
---|
288 | </t> |
---|
289 | <t> |
---|
290 | The response &MUST; include the following header fields: |
---|
291 | <list style="symbols"> |
---|
292 | <t> |
---|
293 | Either a <x:ref>Content-Range</x:ref> header field |
---|
294 | (<xref target="header.content-range"/>) indicating |
---|
295 | the range included with this response, or a multipart/byteranges |
---|
296 | <x:ref>Content-Type</x:ref> including Content-Range fields for each |
---|
297 | part. If a <x:ref>Content-Length</x:ref> header field is present in the |
---|
298 | response, its value &MUST; match the actual number of octets |
---|
299 | transmitted in the message body. |
---|
300 | </t> |
---|
301 | <t> |
---|
302 | Date |
---|
303 | </t> |
---|
304 | <t> |
---|
305 | <x:ref>Cache-Control</x:ref>, <x:ref>ETag</x:ref>, |
---|
306 | <x:ref>Expires</x:ref>, <x:ref>Content-Location</x:ref> and/or |
---|
307 | <x:ref>Vary</x:ref>, if the header field would have been sent in a |
---|
308 | <x:ref>200 (OK)</x:ref> response to the same request |
---|
309 | </t> |
---|
310 | </list> |
---|
311 | </t> |
---|
312 | <t> |
---|
313 | If a 206 is sent in response to a request with an <x:ref>If-Range</x:ref> |
---|
314 | header field, it &SHOULD-NOT; include other representation header fields. |
---|
315 | Otherwise, the response &MUST; include all of the representation header |
---|
316 | fields that would have been returned with a <x:ref>200 (OK)</x:ref> response |
---|
317 | to the same request. |
---|
318 | </t> |
---|
319 | <t> |
---|
320 | Caches &MAY; use a heuristic (see &p6-heuristic;) to determine |
---|
321 | freshness for 206 responses. |
---|
322 | </t> |
---|
323 | </section> |
---|
324 | |
---|
325 | <section title="416 Requested Range Not Satisfiable" anchor="status.416"> |
---|
326 | <iref primary="true" item="416 Requested Range Not Satisfiable (status code)" x:for-anchor=""/> |
---|
327 | <iref primary="true" item="Status Codes" subitem="416 Requested Range Not Satisfiable" x:for-anchor=""/> |
---|
328 | <x:anchor-alias value="416 (Requested Range Not Satisfiable)"/> |
---|
329 | <t> |
---|
330 | A server &SHOULD; return a response with this status code if a request |
---|
331 | included a <x:ref>Range</x:ref> header field (<xref target="header.range"/>), |
---|
332 | and none of the ranges-specifier values in this field overlap the current |
---|
333 | extent of the selected resource, and the request did not include an |
---|
334 | <x:ref>If-Range</x:ref> header field (<xref target="header.if-range"/>). |
---|
335 | (For byte-ranges, this means that the first-byte-pos of all of the |
---|
336 | byte-range-spec values were greater than the current length of the selected |
---|
337 | resource.) |
---|
338 | </t> |
---|
339 | <t> |
---|
340 | When this status code is returned for a byte-range request, the |
---|
341 | response &SHOULD; include a <x:ref>Content-Range</x:ref> header field |
---|
342 | specifying the current length of the representation (see <xref target="header.content-range"/>). |
---|
343 | This response &MUST-NOT; use the multipart/byteranges content-type. For example, |
---|
344 | </t> |
---|
345 | <figure><artwork type="message/http; msgtype="response"" x:indent-with=" "> |
---|
346 | HTTP/1.1 416 Requested Range Not Satisfiable |
---|
347 | Date: Mon, 20 Jan 2012 15:41:54 GMT |
---|
348 | Content-Range: bytes */47022 |
---|
349 | Content-Type: image/gif |
---|
350 | </artwork></figure> |
---|
351 | <x:note> |
---|
352 | <t> |
---|
353 | &Note; Clients cannot depend on servers to send a <x:ref>416 (Requested |
---|
354 | Range Not Satisfiable)</x:ref> response instead of a <x:ref>200 (OK)</x:ref> |
---|
355 | response for an unsatisfiable <x:ref>Range</x:ref> header field, since not |
---|
356 | all servers implement this header field. |
---|
357 | </t> |
---|
358 | </x:note> |
---|
359 | </section> |
---|
360 | </section> |
---|
361 | |
---|
362 | <section title="Responses to a Range Request"> |
---|
363 | <section title="Response to a Single and Multiple Ranges Request"> |
---|
364 | <t> |
---|
365 | When an HTTP message includes the content of a single range (for |
---|
366 | example, a response to a request for a single range, or to a request |
---|
367 | for a set of ranges that overlap without any holes), this content is |
---|
368 | transmitted with a <x:ref>Content-Range</x:ref> header field, and a |
---|
369 | <x:ref>Content-Length</x:ref> header field showing the number of bytes |
---|
370 | actually transferred. For example, |
---|
371 | </t> |
---|
372 | <figure><artwork type="message/http; msgtype="response"" x:indent-with=" "> |
---|
373 | HTTP/1.1 206 Partial Content |
---|
374 | Date: Wed, 15 Nov 1995 06:25:24 GMT |
---|
375 | Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT |
---|
376 | Content-Range: bytes 21010-47021/47022 |
---|
377 | Content-Length: 26012 |
---|
378 | Content-Type: image/gif |
---|
379 | </artwork></figure> |
---|
380 | <t> |
---|
381 | When an HTTP message includes the content of multiple ranges (for |
---|
382 | example, a response to a request for multiple non-overlapping |
---|
383 | ranges), these are transmitted as a multipart message. The multipart |
---|
384 | media type used for this purpose is "multipart/byteranges" as defined |
---|
385 | in <xref target="internet.media.type.multipart.byteranges"/>. |
---|
386 | </t> |
---|
387 | <t> |
---|
388 | A server &MAY; combine requested ranges when those ranges are overlapping |
---|
389 | (see <xref target="overlapping.ranges"/>). |
---|
390 | </t> |
---|
391 | <t> |
---|
392 | A response to a request for a single range &MUST-NOT; be sent using the |
---|
393 | multipart/byteranges media type. A response to a request for |
---|
394 | multiple ranges, whose result is a single range, &MAY; be sent as a |
---|
395 | multipart/byteranges media type with one part. A client that cannot |
---|
396 | decode a multipart/byteranges message &MUST-NOT; ask for multiple |
---|
397 | ranges in a single request. |
---|
398 | </t> |
---|
399 | <t> |
---|
400 | When a client asks for multiple ranges in one request, the |
---|
401 | server &SHOULD; return them in the order that they appeared in the |
---|
402 | request. |
---|
403 | </t> |
---|
404 | </section> |
---|
405 | |
---|
406 | <section title="Combining Ranges" anchor="combining.byte.ranges"> |
---|
407 | <t> |
---|
408 | A response might transfer only a subrange of a representation if the |
---|
409 | connection closed prematurely or if the request used one or more Range |
---|
410 | specifications. After several such transfers, a client might have |
---|
411 | received several ranges of the same representation. These ranges can only |
---|
412 | be safely combined if they all have in common the same strong validator, |
---|
413 | where "strong validator" is defined to be either an entity-tag that is |
---|
414 | not marked as weak (&entity-tags;) or, if no entity-tag is provided, a |
---|
415 | <x:ref>Last-Modified</x:ref> value that is strong in the sense defined by |
---|
416 | &lastmod-comparison;. |
---|
417 | </t> |
---|
418 | <t> |
---|
419 | When a client receives an incomplete <x:ref>200 (OK)</x:ref> or <x:ref>206 (Partial Content)</x:ref> |
---|
420 | response and already has one or more stored responses for the same method |
---|
421 | and effective request URI, all of the stored responses with the same |
---|
422 | strong validator &MAY; be combined with the partial content in this new |
---|
423 | response. If none of the stored responses contain the same strong |
---|
424 | validator, then this new response corresponds to a new representation |
---|
425 | and &MUST-NOT; be combined with the existing stored responses. |
---|
426 | </t> |
---|
427 | <t> |
---|
428 | If the new response is an incomplete <x:ref>200 (OK)</x:ref> response, then the header |
---|
429 | fields of that new response are used for any combined response and replace |
---|
430 | those of the matching stored responses. |
---|
431 | </t> |
---|
432 | <t> |
---|
433 | If the new response is a <x:ref>206 (Partial Content)</x:ref> response and at least one |
---|
434 | of the matching stored responses is a <x:ref>200 (OK)</x:ref>, then the combined response |
---|
435 | header fields consist of the most recent 200 response's header fields. |
---|
436 | If all of the matching stored responses are 206 responses, then the |
---|
437 | stored response with the most header fields is used as the source of |
---|
438 | header fields for the combined response, except that the client &MUST; |
---|
439 | use other header fields provided in the new response, aside from |
---|
440 | <x:ref>Content-Range</x:ref>, to replace all instances of the corresponding |
---|
441 | header fields in the stored response. |
---|
442 | </t> |
---|
443 | <t> |
---|
444 | The combined response message body consists of the union of partial |
---|
445 | content ranges in the new response and each of the selected responses. |
---|
446 | If the union consists of the entire range of the representation, then the |
---|
447 | combined response &MUST; be recorded as a complete <x:ref>200 (OK)</x:ref> |
---|
448 | response with a <x:ref>Content-Length</x:ref> header field that reflects the |
---|
449 | complete length. Otherwise, the combined response(s) &MUST; include a |
---|
450 | <x:ref>Content-Range</x:ref> header field describing the included range(s) |
---|
451 | and be recorded as incomplete. If the union consists of a discontinuous |
---|
452 | range of the representation, then the client &MAY; store it as either a |
---|
453 | multipart range response or as multiple <x:ref>206</x:ref> responses with |
---|
454 | one continuous range each. |
---|
455 | </t> |
---|
456 | </section> |
---|
457 | </section> |
---|
458 | |
---|
459 | <section title="Header Field Definitions" anchor="header.field.definitions"> |
---|
460 | <t> |
---|
461 | This section defines the syntax and semantics of HTTP/1.1 header fields |
---|
462 | related to range requests and partial responses. |
---|
463 | </t> |
---|
464 | |
---|
465 | <section title="Accept-Ranges" anchor="header.accept-ranges"> |
---|
466 | <iref primary="true" item="Accept-Ranges header field" x:for-anchor=""/> |
---|
467 | <iref primary="true" item="Header Fields" subitem="Accept-Ranges" x:for-anchor=""/> |
---|
468 | <x:anchor-alias value="Accept-Ranges"/> |
---|
469 | <x:anchor-alias value="acceptable-ranges"/> |
---|
470 | <t> |
---|
471 | The "Accept-Ranges" header field allows a resource to indicate |
---|
472 | its acceptance of range requests. |
---|
473 | </t> |
---|
474 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Ranges"/><iref primary="true" item="Grammar" subitem="acceptable-ranges"/> |
---|
475 | <x:ref>Accept-Ranges</x:ref> = <x:ref>acceptable-ranges</x:ref> |
---|
476 | <x:ref>acceptable-ranges</x:ref> = 1#<x:ref>range-unit</x:ref> / "none" |
---|
477 | </artwork></figure> |
---|
478 | <t> |
---|
479 | Origin servers that accept byte-range requests &MAY; send |
---|
480 | </t> |
---|
481 | <figure><artwork type="example"> |
---|
482 | Accept-Ranges: bytes |
---|
483 | </artwork></figure> |
---|
484 | <t> |
---|
485 | but are not required to do so. Clients &MAY; generate range |
---|
486 | requests without having received this header field for the resource |
---|
487 | involved. Range units are defined in <xref target="range.units"/>. |
---|
488 | </t> |
---|
489 | <t> |
---|
490 | Servers that do not accept any kind of range request for a |
---|
491 | resource &MAY; send |
---|
492 | </t> |
---|
493 | <figure><artwork type="example"> |
---|
494 | Accept-Ranges: none |
---|
495 | </artwork></figure> |
---|
496 | <t> |
---|
497 | to advise the client not to attempt a range request. |
---|
498 | </t> |
---|
499 | </section> |
---|
500 | |
---|
501 | <section title="Content-Range" anchor="header.content-range"> |
---|
502 | <iref primary="true" item="Content-Range header field" x:for-anchor=""/> |
---|
503 | <iref primary="true" item="Header Fields" subitem="Content-Range" x:for-anchor=""/> |
---|
504 | <x:anchor-alias value="byte-content-range-spec"/> |
---|
505 | <x:anchor-alias value="byte-range-resp-spec"/> |
---|
506 | <x:anchor-alias value="Content-Range"/> |
---|
507 | <x:anchor-alias value="instance-length"/> |
---|
508 | <x:anchor-alias value="other-content-range-spec"/> |
---|
509 | <x:anchor-alias value="other-range-resp-spec"/> |
---|
510 | <t> |
---|
511 | The "Content-Range" header field is sent with a partial representation to |
---|
512 | specify where in the full representation the payload body is intended to be |
---|
513 | applied. |
---|
514 | </t> |
---|
515 | <t> |
---|
516 | Range units are defined in <xref target="range.units"/>. |
---|
517 | </t> |
---|
518 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Range"/><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"/> |
---|
519 | <x:ref>Content-Range</x:ref> = <x:ref>byte-content-range-spec</x:ref> |
---|
520 | / <x:ref>other-content-range-spec</x:ref> |
---|
521 | |
---|
522 | <x:ref>byte-content-range-spec</x:ref> = <x:ref>bytes-unit</x:ref> <x:ref>SP</x:ref> |
---|
523 | <x:ref>byte-range-resp-spec</x:ref> "/" |
---|
524 | ( <x:ref>instance-length</x:ref> / "*" ) |
---|
525 | |
---|
526 | <x:ref>byte-range-resp-spec</x:ref> = (<x:ref>first-byte-pos</x:ref> "-" <x:ref>last-byte-pos</x:ref>) |
---|
527 | / "*" |
---|
528 | |
---|
529 | <x:ref>instance-length</x:ref> = 1*<x:ref>DIGIT</x:ref> |
---|
530 | |
---|
531 | <x:ref>other-content-range-spec</x:ref> = <x:ref>other-range-unit</x:ref> <x:ref>SP</x:ref> |
---|
532 | <x:ref>other-range-resp-spec</x:ref> |
---|
533 | <x:ref>other-range-resp-spec</x:ref> = *<x:ref>CHAR</x:ref> |
---|
534 | </artwork></figure> |
---|
535 | <t> |
---|
536 | The header field &SHOULD; indicate the total length of the full representation, |
---|
537 | unless this length is unknown or difficult to determine. The asterisk |
---|
538 | "*" character means that the instance-length is unknown at the time |
---|
539 | when the response was generated. |
---|
540 | </t> |
---|
541 | <t> |
---|
542 | Unlike byte-ranges-specifier values (see <xref target="byte.ranges"/>), a byte-range-resp-spec |
---|
543 | &MUST; only specify one range, and &MUST; contain |
---|
544 | absolute byte positions for both the first and last byte of the |
---|
545 | range. |
---|
546 | </t> |
---|
547 | <t> |
---|
548 | A byte-content-range-spec with a byte-range-resp-spec whose last-byte-pos |
---|
549 | value is less than its first-byte-pos value, or whose |
---|
550 | instance-length value is less than or equal to its last-byte-pos |
---|
551 | value, is invalid. The recipient of an invalid byte-content-range-spec |
---|
552 | &MUST; ignore it and any content transferred along with it. |
---|
553 | </t> |
---|
554 | <t> |
---|
555 | In the case of a byte range request: |
---|
556 | A server sending a response with status code <x:ref>416 (Requested Range Not |
---|
557 | Satisfiable)</x:ref> &SHOULD; include a Content-Range field with a byte-range-resp-spec |
---|
558 | of "*". The instance-length specifies the current length of |
---|
559 | the selected resource. A response with status code <x:ref>206 (Partial Content)</x:ref> |
---|
560 | &MUST-NOT; include a Content-Range field with a byte-range-resp-spec of "*". |
---|
561 | </t> |
---|
562 | <t> |
---|
563 | The "Content-Range" header field has no meaning for status codes that do not |
---|
564 | explicitly describe its semantic. Currently, only status codes |
---|
565 | <x:ref>206 (Partial Content)</x:ref> and <x:ref>416 (Requested Range Not Satisfiable)</x:ref> describe |
---|
566 | the meaning of this header field. |
---|
567 | </t> |
---|
568 | <t> |
---|
569 | Examples of byte-content-range-spec values, assuming that the representation |
---|
570 | contains a total of 1234 bytes: |
---|
571 | <list style="symbols"> |
---|
572 | <t> |
---|
573 | The first 500 bytes: |
---|
574 | <figure><artwork type="example" x:indent-with=" "> |
---|
575 | bytes 0-499/1234 |
---|
576 | </artwork></figure> |
---|
577 | </t> |
---|
578 | <t> |
---|
579 | The second 500 bytes: |
---|
580 | <figure><artwork type="example" x:indent-with=" "> |
---|
581 | bytes 500-999/1234 |
---|
582 | </artwork></figure> |
---|
583 | </t> |
---|
584 | <t> |
---|
585 | All except for the first 500 bytes: |
---|
586 | <figure><artwork type="example" x:indent-with=" "> |
---|
587 | bytes 500-1233/1234 |
---|
588 | </artwork></figure> |
---|
589 | </t> |
---|
590 | <t> |
---|
591 | The last 500 bytes: |
---|
592 | <figure><artwork type="example" x:indent-with=" "> |
---|
593 | bytes 734-1233/1234 |
---|
594 | </artwork></figure> |
---|
595 | </t> |
---|
596 | </list> |
---|
597 | </t> |
---|
598 | <t> |
---|
599 | If the server ignores a byte-range-spec (for example if it is |
---|
600 | syntactically invalid, or if it might be seen as a denial-of-service |
---|
601 | attack), the server &SHOULD; treat the request as if the invalid <x:ref>Range</x:ref> |
---|
602 | header field did not exist. (Normally, this means return a <x:ref>200 (OK)</x:ref> |
---|
603 | response containing the full representation). |
---|
604 | </t> |
---|
605 | </section> |
---|
606 | |
---|
607 | <section title="If-Range" anchor="header.if-range"> |
---|
608 | <iref primary="true" item="If-Range header field" x:for-anchor=""/> |
---|
609 | <iref primary="true" item="Header Fields" subitem="If-Range" x:for-anchor=""/> |
---|
610 | <x:anchor-alias value="If-Range"/> |
---|
611 | <t> |
---|
612 | If a client has a partial copy of a representation and wishes |
---|
613 | to have an up-to-date copy of the entire representation, it could use the |
---|
614 | <x:ref>Range</x:ref> header field with a conditional GET (using |
---|
615 | either or both of <x:ref>If-Unmodified-Since</x:ref> and |
---|
616 | <x:ref>If-Match</x:ref>.) However, if the condition fails because the |
---|
617 | representation has been modified, the client would then have to make a |
---|
618 | second request to obtain the entire current representation. |
---|
619 | </t> |
---|
620 | <t> |
---|
621 | The "If-Range" header field allows a client to "short-circuit" the second |
---|
622 | request. Informally, its meaning is "if the representation is unchanged, send |
---|
623 | me the part(s) that I am missing; otherwise, send me the entire new |
---|
624 | representation". |
---|
625 | </t> |
---|
626 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Range"/> |
---|
627 | <x:ref>If-Range</x:ref> = <x:ref>entity-tag</x:ref> / <x:ref>HTTP-date</x:ref> |
---|
628 | </artwork></figure> |
---|
629 | <t> |
---|
630 | Clients &MUST-NOT; use an entity-tag marked as weak in an If-Range |
---|
631 | field value and &MUST-NOT; use a <x:ref>Last-Modified</x:ref> date in an |
---|
632 | If-Range field value unless it has no entity-tag for the representation and |
---|
633 | the Last-Modified date it does have for the representation is strong |
---|
634 | in the sense defined by &lastmod-comparison;. |
---|
635 | </t> |
---|
636 | <t> |
---|
637 | A server that evaluates a conditional range request that is applicable |
---|
638 | to one of its representations &MUST; evaluate the condition as false if |
---|
639 | the entity-tag used as a validator is marked as weak or, when an HTTP-date |
---|
640 | is used as the validator, if the date value is not strong in the sense |
---|
641 | defined by &lastmod-comparison;. (A server can distinguish between a |
---|
642 | valid HTTP-date and any form of entity-tag by examining the first |
---|
643 | two characters.) |
---|
644 | </t> |
---|
645 | <t> |
---|
646 | The If-Range header field &SHOULD; only be sent by clients together with |
---|
647 | a Range header field. The If-Range header field &MUST; be ignored if it |
---|
648 | is received in a request that does not include a Range header field. |
---|
649 | The If-Range header field &MUST; be ignored by a server that does not |
---|
650 | support the sub-range operation. |
---|
651 | </t> |
---|
652 | <t> |
---|
653 | If the validator given in the If-Range header field matches the current |
---|
654 | validator for the selected representation of the target resource, then |
---|
655 | the server &SHOULD; send the specified sub-range of the representation |
---|
656 | using a <x:ref>206 (Partial Content)</x:ref> response. If the validator does not match, |
---|
657 | then the server &SHOULD; send the entire representation using a <x:ref>200 (OK)</x:ref> |
---|
658 | response. |
---|
659 | </t> |
---|
660 | </section> |
---|
661 | |
---|
662 | <section title="Range" anchor="header.range"> |
---|
663 | <iref primary="true" item="Range header field" x:for-anchor=""/> |
---|
664 | <iref primary="true" item="Header Fields" subitem="Range" x:for-anchor=""/> |
---|
665 | |
---|
666 | <section title="Byte Ranges" anchor="byte.ranges"> |
---|
667 | <t> |
---|
668 | Since all HTTP representations are transferred as sequences |
---|
669 | of bytes, the concept of a byte range is meaningful for any HTTP |
---|
670 | representation. (However, not all clients and servers need to support byte-range |
---|
671 | operations.) |
---|
672 | </t> |
---|
673 | <t> |
---|
674 | Byte range specifications in HTTP apply to the sequence of bytes in |
---|
675 | the representation body (not necessarily the same as the message body). |
---|
676 | </t> |
---|
677 | <t anchor="rule.ranges-specifier"> |
---|
678 | <x:anchor-alias value="byte-range-set"/> |
---|
679 | <x:anchor-alias value="byte-range-spec"/> |
---|
680 | <x:anchor-alias value="byte-ranges-specifier"/> |
---|
681 | <x:anchor-alias value="first-byte-pos"/> |
---|
682 | <x:anchor-alias value="last-byte-pos"/> |
---|
683 | <x:anchor-alias value="ranges-specifier"/> |
---|
684 | <x:anchor-alias value="suffix-byte-range-spec"/> |
---|
685 | <x:anchor-alias value="suffix-length"/> |
---|
686 | A byte range operation &MAY; specify a single range of bytes, or a set |
---|
687 | of ranges within a single representation. |
---|
688 | </t> |
---|
689 | <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"/> |
---|
690 | <x:ref>byte-ranges-specifier</x:ref> = <x:ref>bytes-unit</x:ref> "=" <x:ref>byte-range-set</x:ref> |
---|
691 | <x:ref>byte-range-set</x:ref> = 1#( <x:ref>byte-range-spec</x:ref> / <x:ref>suffix-byte-range-spec</x:ref> ) |
---|
692 | <x:ref>byte-range-spec</x:ref> = <x:ref>first-byte-pos</x:ref> "-" [ <x:ref>last-byte-pos</x:ref> ] |
---|
693 | <x:ref>first-byte-pos</x:ref> = 1*<x:ref>DIGIT</x:ref> |
---|
694 | <x:ref>last-byte-pos</x:ref> = 1*<x:ref>DIGIT</x:ref> |
---|
695 | </artwork></figure> |
---|
696 | <t> |
---|
697 | The first-byte-pos value in a byte-range-spec gives the byte-offset |
---|
698 | of the first byte in a range. The last-byte-pos value gives the |
---|
699 | byte-offset of the last byte in the range; that is, the byte |
---|
700 | positions specified are inclusive. Byte offsets start at zero. |
---|
701 | </t> |
---|
702 | <t> |
---|
703 | If the last-byte-pos value is present, it &MUST; be greater than or |
---|
704 | equal to the first-byte-pos in that byte-range-spec, or the byte-range-spec |
---|
705 | is syntactically invalid. The recipient of a byte-range-set |
---|
706 | that includes one or more syntactically invalid byte-range-spec |
---|
707 | values &MUST; ignore the header field that includes that byte-range-set. |
---|
708 | </t> |
---|
709 | <t> |
---|
710 | If the last-byte-pos value is absent, or if the value is greater than |
---|
711 | or equal to the current length of the representation body, last-byte-pos is |
---|
712 | taken to be equal to one less than the current length of the representation |
---|
713 | in bytes. |
---|
714 | </t> |
---|
715 | <t> |
---|
716 | By its choice of last-byte-pos, a client can limit the number of |
---|
717 | bytes retrieved without knowing the size of the representation. |
---|
718 | </t> |
---|
719 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="suffix-byte-range-spec"/><iref primary="true" item="Grammar" subitem="suffix-length"/> |
---|
720 | <x:ref>suffix-byte-range-spec</x:ref> = "-" <x:ref>suffix-length</x:ref> |
---|
721 | <x:ref>suffix-length</x:ref> = 1*<x:ref>DIGIT</x:ref> |
---|
722 | </artwork></figure> |
---|
723 | <t> |
---|
724 | A suffix-byte-range-spec is used to specify the suffix of the |
---|
725 | representation body, of a length given by the suffix-length value. (That is, |
---|
726 | this form specifies the last N bytes of a representation.) If the |
---|
727 | representation is shorter than the specified suffix-length, the entire |
---|
728 | representation is used. |
---|
729 | </t> |
---|
730 | <t> |
---|
731 | If a syntactically valid byte-range-set includes at least one byte-range-spec |
---|
732 | whose first-byte-pos is less than the current length of |
---|
733 | the representation, or at least one suffix-byte-range-spec with a non-zero |
---|
734 | suffix-length, then the byte-range-set is satisfiable. |
---|
735 | Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set |
---|
736 | is unsatisfiable, the server &SHOULD; return a response with a |
---|
737 | <x:ref>416 (Requested Range Not Satisfiable)</x:ref> status code. Otherwise, the server |
---|
738 | &SHOULD; return a response with a <x:ref>206 (Partial Content)</x:ref> status code |
---|
739 | containing the satisfiable ranges of the representation. |
---|
740 | </t> |
---|
741 | <t> |
---|
742 | In the byte range syntax, <x:ref>first-byte-pos</x:ref>, |
---|
743 | <x:ref>last-byte-pos</x:ref>, and <x:ref>suffix-length</x:ref> are |
---|
744 | expressed as decimal number of octets. Since there is no predefined limit |
---|
745 | to the length of an HTTP payload, recipients &SHOULD; anticipate |
---|
746 | potentially large decimal numerals and prevent parsing errors due to integer |
---|
747 | conversion overflows. |
---|
748 | </t> |
---|
749 | <t> |
---|
750 | Examples of byte-ranges-specifier values (assuming a representation of |
---|
751 | length 10000): |
---|
752 | <list style="symbols"> |
---|
753 | <t>The first 500 bytes (byte offsets 0-499, inclusive): |
---|
754 | <figure><artwork type="example" x:indent-with=" "> |
---|
755 | bytes=0-499 |
---|
756 | </artwork></figure> |
---|
757 | </t> |
---|
758 | <t>The second 500 bytes (byte offsets 500-999, inclusive): |
---|
759 | <figure><artwork type="example" x:indent-with=" "> |
---|
760 | bytes=500-999 |
---|
761 | </artwork></figure> |
---|
762 | </t> |
---|
763 | <t>The final 500 bytes (byte offsets 9500-9999, inclusive): |
---|
764 | <figure><artwork type="example" x:indent-with=" "> |
---|
765 | bytes=-500 |
---|
766 | </artwork></figure> |
---|
767 | Or: |
---|
768 | <figure><artwork type="example" x:indent-with=" "> |
---|
769 | bytes=9500- |
---|
770 | </artwork></figure> |
---|
771 | </t> |
---|
772 | <t>The first and last bytes only (bytes 0 and 9999): |
---|
773 | <figure><artwork type="example" x:indent-with=" "> |
---|
774 | bytes=0-0,-1 |
---|
775 | </artwork></figure> |
---|
776 | </t> |
---|
777 | <t>Several legal but not canonical specifications of the second 500 |
---|
778 | bytes (byte offsets 500-999, inclusive): |
---|
779 | <figure><artwork type="example" x:indent-with=" "> |
---|
780 | bytes=500-600,601-999 |
---|
781 | bytes=500-700,601-999 |
---|
782 | </artwork></figure> |
---|
783 | </t> |
---|
784 | </list> |
---|
785 | </t> |
---|
786 | </section> |
---|
787 | |
---|
788 | <section title="Range Retrieval Requests" anchor="range.retrieval.requests"> |
---|
789 | <x:anchor-alias value="Range"/> |
---|
790 | <x:anchor-alias value="other-ranges-specifier"/> |
---|
791 | <x:anchor-alias value="other-range-set"/> |
---|
792 | <t> |
---|
793 | The "Range" header field defines the GET method (conditional or |
---|
794 | not) to request one or more sub-ranges of the response representation body, instead |
---|
795 | of the entire representation body. |
---|
796 | </t> |
---|
797 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Range"/> |
---|
798 | <x:ref>Range</x:ref> = <x:ref>byte-ranges-specifier</x:ref> / <x:ref>other-ranges-specifier</x:ref> |
---|
799 | <x:ref>other-ranges-specifier</x:ref> = <x:ref>other-range-unit</x:ref> "=" <x:ref>other-range-set</x:ref> |
---|
800 | <x:ref>other-range-set</x:ref> = 1*<x:ref>CHAR</x:ref> |
---|
801 | </artwork></figure> |
---|
802 | <t> |
---|
803 | A server &MAY; ignore the Range header field. However, origin |
---|
804 | servers and intermediate caches ought to support byte ranges when |
---|
805 | possible, since Range supports efficient recovery from partially |
---|
806 | failed transfers, and supports efficient partial retrieval of large |
---|
807 | representations. |
---|
808 | </t> |
---|
809 | <t> |
---|
810 | If the server supports the Range header field and the specified range or |
---|
811 | ranges are appropriate for the representation: |
---|
812 | <list style="symbols"> |
---|
813 | <t>The presence of a Range header field in an unconditional GET modifies |
---|
814 | what is returned if the GET is otherwise successful. In other |
---|
815 | words, the response carries a status code of <x:ref>206 (Partial Content)</x:ref> |
---|
816 | instead of <x:ref>200 (OK)</x:ref>.</t> |
---|
817 | |
---|
818 | <t>The presence of a Range header field in a conditional GET (a request |
---|
819 | using one or both of <x:ref>If-Modified-Since</x:ref> and |
---|
820 | <x:ref>If-None-Match</x:ref>, or one or both of |
---|
821 | <x:ref>If-Unmodified-Since</x:ref> and <x:ref>If-Match</x:ref>) modifies |
---|
822 | what is returned if the GET is otherwise successful and the |
---|
823 | condition is true. It does not affect the <x:ref>304 (Not Modified)</x:ref> |
---|
824 | response returned if the conditional is false.</t> |
---|
825 | </list> |
---|
826 | </t> |
---|
827 | <t> |
---|
828 | In some cases, it might be more appropriate to use the If-Range |
---|
829 | header field (see <xref target="header.if-range"/>) in addition to the Range |
---|
830 | header field. |
---|
831 | </t> |
---|
832 | <t> |
---|
833 | If a proxy that supports ranges receives a Range request, forwards |
---|
834 | the request to an inbound server, and receives an entire representation in |
---|
835 | reply, it &MAY; only return the requested range to its client. |
---|
836 | </t> |
---|
837 | </section> |
---|
838 | </section> |
---|
839 | </section> |
---|
840 | |
---|
841 | <section title="IANA Considerations" anchor="IANA.considerations"> |
---|
842 | |
---|
843 | <section title="Status Code Registration" anchor="status.code.registration"> |
---|
844 | <t> |
---|
845 | The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-status-codes"/> |
---|
846 | shall be updated with the registrations below: |
---|
847 | </t> |
---|
848 | <?BEGININC p5-range.iana-status-codes ?> |
---|
849 | <!--AUTOGENERATED FROM extract-status-code-defs.xslt, do not edit manually--> |
---|
850 | <texttable align="left" suppress-title="true" anchor="iana.status.code.registration.table"> |
---|
851 | <ttcol>Value</ttcol> |
---|
852 | <ttcol>Description</ttcol> |
---|
853 | <ttcol>Reference</ttcol> |
---|
854 | <c>206</c> |
---|
855 | <c>Partial Content</c> |
---|
856 | <c> |
---|
857 | <xref target="status.206"/> |
---|
858 | </c> |
---|
859 | <c>416</c> |
---|
860 | <c>Requested Range Not Satisfiable</c> |
---|
861 | <c> |
---|
862 | <xref target="status.416"/> |
---|
863 | </c> |
---|
864 | </texttable> |
---|
865 | <!--(END)--> |
---|
866 | <?ENDINC p5-range.iana-status-codes ?> |
---|
867 | </section> |
---|
868 | |
---|
869 | <section title="Header Field Registration" anchor="header.field.registration"> |
---|
870 | <t> |
---|
871 | The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated |
---|
872 | with the permanent registrations below (see <xref target="RFC3864"/>): |
---|
873 | </t> |
---|
874 | <?BEGININC p5-range.iana-headers ?> |
---|
875 | <!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually--> |
---|
876 | <texttable align="left" suppress-title="true" anchor="iana.header.registration.table"> |
---|
877 | <ttcol>Header Field Name</ttcol> |
---|
878 | <ttcol>Protocol</ttcol> |
---|
879 | <ttcol>Status</ttcol> |
---|
880 | <ttcol>Reference</ttcol> |
---|
881 | |
---|
882 | <c>Accept-Ranges</c> |
---|
883 | <c>http</c> |
---|
884 | <c>standard</c> |
---|
885 | <c> |
---|
886 | <xref target="header.accept-ranges"/> |
---|
887 | </c> |
---|
888 | <c>Content-Range</c> |
---|
889 | <c>http</c> |
---|
890 | <c>standard</c> |
---|
891 | <c> |
---|
892 | <xref target="header.content-range"/> |
---|
893 | </c> |
---|
894 | <c>If-Range</c> |
---|
895 | <c>http</c> |
---|
896 | <c>standard</c> |
---|
897 | <c> |
---|
898 | <xref target="header.if-range"/> |
---|
899 | </c> |
---|
900 | <c>Range</c> |
---|
901 | <c>http</c> |
---|
902 | <c>standard</c> |
---|
903 | <c> |
---|
904 | <xref target="header.range"/> |
---|
905 | </c> |
---|
906 | </texttable> |
---|
907 | <!--(END)--> |
---|
908 | <?ENDINC p5-range.iana-headers ?> |
---|
909 | <t> |
---|
910 | The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force". |
---|
911 | </t> |
---|
912 | </section> |
---|
913 | |
---|
914 | <section title="Range Specifier Registration" anchor="range.specifier.registration"> |
---|
915 | <t> |
---|
916 | The registration procedure for HTTP Range Specifiers is defined by |
---|
917 | <xref target="range.specifier.registry"/> of this document. |
---|
918 | </t> |
---|
919 | <t> |
---|
920 | The HTTP Range Specifier Registry shall be created at <eref target="http://www.iana.org/assignments/http-range-specifiers"/> |
---|
921 | and be populated with the registrations below: |
---|
922 | </t> |
---|
923 | <texttable align="left" suppress-title="true" anchor="iana.range.specifiers.table"> |
---|
924 | <ttcol>Range Specifier Name</ttcol> |
---|
925 | <ttcol>Description</ttcol> |
---|
926 | <ttcol>Reference</ttcol> |
---|
927 | |
---|
928 | <c>bytes</c> |
---|
929 | <c>a range of octets</c> |
---|
930 | <c><xref target="range.units"/></c> |
---|
931 | |
---|
932 | <c>none</c> |
---|
933 | <c>reserved as keyword, indicating no ranges are supported</c> |
---|
934 | <c><xref target="header.accept-ranges"/></c> |
---|
935 | </texttable> |
---|
936 | <t> |
---|
937 | The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force". |
---|
938 | </t> |
---|
939 | </section> |
---|
940 | </section> |
---|
941 | |
---|
942 | <section title="Security Considerations" anchor="security.considerations"> |
---|
943 | <t> |
---|
944 | This section is meant to inform application developers, information |
---|
945 | providers, and users of the security limitations in HTTP/1.1 as |
---|
946 | described by this document. The discussion does not include |
---|
947 | definitive solutions to the problems revealed, though it does make |
---|
948 | some suggestions for reducing security risks. |
---|
949 | </t> |
---|
950 | <section title="Overlapping Ranges" anchor="overlapping.ranges"> |
---|
951 | <t> |
---|
952 | Range requests containing overlapping ranges can lead to the situation |
---|
953 | where a server is sending far more data than the size of the complete |
---|
954 | resource representation. |
---|
955 | </t> |
---|
956 | </section> |
---|
957 | </section> |
---|
958 | |
---|
959 | <section title="Acknowledgments" anchor="acks"> |
---|
960 | <t> |
---|
961 | See &acks;. |
---|
962 | </t> |
---|
963 | </section> |
---|
964 | </middle> |
---|
965 | <back> |
---|
966 | |
---|
967 | <references title="Normative References"> |
---|
968 | |
---|
969 | <reference anchor="Part1"> |
---|
970 | <front> |
---|
971 | <title>HTTP/1.1, part 1: Message Routing and Syntax"</title> |
---|
972 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
973 | <organization abbrev="Adobe">Adobe Systems Incorporated</organization> |
---|
974 | <address><email>fielding@gbiv.com</email></address> |
---|
975 | </author> |
---|
976 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
977 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
978 | <address><email>ylafon@w3.org</email></address> |
---|
979 | </author> |
---|
980 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
981 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
982 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
983 | </author> |
---|
984 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
985 | </front> |
---|
986 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"/> |
---|
987 | <x:source href="p1-messaging.xml" basename="p1-messaging"> |
---|
988 | <x:defines>Content-Length</x:defines> |
---|
989 | </x:source> |
---|
990 | </reference> |
---|
991 | |
---|
992 | <reference anchor="Part2"> |
---|
993 | <front> |
---|
994 | <title>HTTP/1.1, part 2: Semantics and Payloads</title> |
---|
995 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
996 | <organization abbrev="Adobe">Adobe Systems Incorporated</organization> |
---|
997 | <address><email>fielding@gbiv.com</email></address> |
---|
998 | </author> |
---|
999 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
1000 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
1001 | <address><email>ylafon@w3.org</email></address> |
---|
1002 | </author> |
---|
1003 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
1004 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
1005 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
1006 | </author> |
---|
1007 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
1008 | </front> |
---|
1009 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;"/> |
---|
1010 | <x:source href="p2-semantics.xml" basename="p2-semantics"> |
---|
1011 | <x:defines>200 (OK)</x:defines> |
---|
1012 | <x:defines>410 (Gone)</x:defines> |
---|
1013 | <x:defines>Content-Location</x:defines> |
---|
1014 | <x:defines>Content-Type</x:defines> |
---|
1015 | <x:defines>Location</x:defines> |
---|
1016 | </x:source> |
---|
1017 | </reference> |
---|
1018 | |
---|
1019 | <reference anchor="Part4"> |
---|
1020 | <front> |
---|
1021 | <title>HTTP/1.1, part 4: Conditional Requests</title> |
---|
1022 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
1023 | <organization abbrev="Adobe">Adobe Systems Incorporated</organization> |
---|
1024 | <address><email>fielding@gbiv.com</email></address> |
---|
1025 | </author> |
---|
1026 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
1027 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
1028 | <address><email>ylafon@w3.org</email></address> |
---|
1029 | </author> |
---|
1030 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
1031 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
1032 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
1033 | </author> |
---|
1034 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
1035 | </front> |
---|
1036 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p4-conditional-&ID-VERSION;"/> |
---|
1037 | <x:source href="p4-conditional.xml" basename="p4-conditional"> |
---|
1038 | <x:defines>304 (Not Modified)</x:defines> |
---|
1039 | <x:defines>ETag</x:defines> |
---|
1040 | <x:defines>If-Match</x:defines> |
---|
1041 | <x:defines>If-Modified-Since</x:defines> |
---|
1042 | <x:defines>If-None-Match</x:defines> |
---|
1043 | <x:defines>If-Unmodified-Since</x:defines> |
---|
1044 | <x:defines>Last-Modified</x:defines> |
---|
1045 | </x:source> |
---|
1046 | </reference> |
---|
1047 | |
---|
1048 | <reference anchor="Part6"> |
---|
1049 | <front> |
---|
1050 | <title>HTTP/1.1, part 6: Caching</title> |
---|
1051 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
1052 | <organization abbrev="Adobe">Adobe Systems Incorporated</organization> |
---|
1053 | <address><email>fielding@gbiv.com</email></address> |
---|
1054 | </author> |
---|
1055 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
1056 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
1057 | <address><email>ylafon@w3.org</email></address> |
---|
1058 | </author> |
---|
1059 | <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor"> |
---|
1060 | <organization>Rackspace</organization> |
---|
1061 | <address><email>mnot@mnot.net</email></address> |
---|
1062 | </author> |
---|
1063 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
1064 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
1065 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
1066 | </author> |
---|
1067 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
1068 | </front> |
---|
1069 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/> |
---|
1070 | <x:source href="p6-cache.xml" basename="p6-cache"> |
---|
1071 | <x:defines>Cache-Control</x:defines> |
---|
1072 | <x:defines>Expires</x:defines> |
---|
1073 | <x:defines>Vary</x:defines> |
---|
1074 | </x:source> |
---|
1075 | </reference> |
---|
1076 | |
---|
1077 | <reference anchor="RFC2046"> |
---|
1078 | <front> |
---|
1079 | <title abbrev="Media Types">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title> |
---|
1080 | <author initials="N." surname="Freed" fullname="Ned Freed"> |
---|
1081 | <organization>Innosoft International, Inc.</organization> |
---|
1082 | <address><email>ned@innosoft.com</email></address> |
---|
1083 | </author> |
---|
1084 | <author initials="N." surname="Borenstein" fullname="Nathaniel S. Borenstein"> |
---|
1085 | <organization>First Virtual Holdings</organization> |
---|
1086 | <address><email>nsb@nsb.fv.com</email></address> |
---|
1087 | </author> |
---|
1088 | <date month="November" year="1996"/> |
---|
1089 | </front> |
---|
1090 | <seriesInfo name="RFC" value="2046"/> |
---|
1091 | </reference> |
---|
1092 | |
---|
1093 | <reference anchor="RFC2119"> |
---|
1094 | <front> |
---|
1095 | <title>Key words for use in RFCs to Indicate Requirement Levels</title> |
---|
1096 | <author initials="S." surname="Bradner" fullname="Scott Bradner"> |
---|
1097 | <organization>Harvard University</organization> |
---|
1098 | <address><email>sob@harvard.edu</email></address> |
---|
1099 | </author> |
---|
1100 | <date month="March" year="1997"/> |
---|
1101 | </front> |
---|
1102 | <seriesInfo name="BCP" value="14"/> |
---|
1103 | <seriesInfo name="RFC" value="2119"/> |
---|
1104 | </reference> |
---|
1105 | |
---|
1106 | <reference anchor="RFC5234"> |
---|
1107 | <front> |
---|
1108 | <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title> |
---|
1109 | <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor"> |
---|
1110 | <organization>Brandenburg InternetWorking</organization> |
---|
1111 | <address> |
---|
1112 | <email>dcrocker@bbiw.net</email> |
---|
1113 | </address> |
---|
1114 | </author> |
---|
1115 | <author initials="P." surname="Overell" fullname="Paul Overell"> |
---|
1116 | <organization>THUS plc.</organization> |
---|
1117 | <address> |
---|
1118 | <email>paul.overell@thus.net</email> |
---|
1119 | </address> |
---|
1120 | </author> |
---|
1121 | <date month="January" year="2008"/> |
---|
1122 | </front> |
---|
1123 | <seriesInfo name="STD" value="68"/> |
---|
1124 | <seriesInfo name="RFC" value="5234"/> |
---|
1125 | </reference> |
---|
1126 | |
---|
1127 | </references> |
---|
1128 | |
---|
1129 | <references title="Informative References"> |
---|
1130 | |
---|
1131 | <reference anchor="RFC2616"> |
---|
1132 | <front> |
---|
1133 | <title>Hypertext Transfer Protocol -- HTTP/1.1</title> |
---|
1134 | <author initials="R." surname="Fielding" fullname="R. Fielding"> |
---|
1135 | <organization>University of California, Irvine</organization> |
---|
1136 | <address><email>fielding@ics.uci.edu</email></address> |
---|
1137 | </author> |
---|
1138 | <author initials="J." surname="Gettys" fullname="J. Gettys"> |
---|
1139 | <organization>W3C</organization> |
---|
1140 | <address><email>jg@w3.org</email></address> |
---|
1141 | </author> |
---|
1142 | <author initials="J." surname="Mogul" fullname="J. Mogul"> |
---|
1143 | <organization>Compaq Computer Corporation</organization> |
---|
1144 | <address><email>mogul@wrl.dec.com</email></address> |
---|
1145 | </author> |
---|
1146 | <author initials="H." surname="Frystyk" fullname="H. Frystyk"> |
---|
1147 | <organization>MIT Laboratory for Computer Science</organization> |
---|
1148 | <address><email>frystyk@w3.org</email></address> |
---|
1149 | </author> |
---|
1150 | <author initials="L." surname="Masinter" fullname="L. Masinter"> |
---|
1151 | <organization>Xerox Corporation</organization> |
---|
1152 | <address><email>masinter@parc.xerox.com</email></address> |
---|
1153 | </author> |
---|
1154 | <author initials="P." surname="Leach" fullname="P. Leach"> |
---|
1155 | <organization>Microsoft Corporation</organization> |
---|
1156 | <address><email>paulle@microsoft.com</email></address> |
---|
1157 | </author> |
---|
1158 | <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee"> |
---|
1159 | <organization>W3C</organization> |
---|
1160 | <address><email>timbl@w3.org</email></address> |
---|
1161 | </author> |
---|
1162 | <date month="June" year="1999"/> |
---|
1163 | </front> |
---|
1164 | <seriesInfo name="RFC" value="2616"/> |
---|
1165 | </reference> |
---|
1166 | |
---|
1167 | <reference anchor='RFC3864'> |
---|
1168 | <front> |
---|
1169 | <title>Registration Procedures for Message Header Fields</title> |
---|
1170 | <author initials='G.' surname='Klyne' fullname='G. Klyne'> |
---|
1171 | <organization>Nine by Nine</organization> |
---|
1172 | <address><email>GK-IETF@ninebynine.org</email></address> |
---|
1173 | </author> |
---|
1174 | <author initials='M.' surname='Nottingham' fullname='M. Nottingham'> |
---|
1175 | <organization>BEA Systems</organization> |
---|
1176 | <address><email>mnot@pobox.com</email></address> |
---|
1177 | </author> |
---|
1178 | <author initials='J.' surname='Mogul' fullname='J. Mogul'> |
---|
1179 | <organization>HP Labs</organization> |
---|
1180 | <address><email>JeffMogul@acm.org</email></address> |
---|
1181 | </author> |
---|
1182 | <date year='2004' month='September' /> |
---|
1183 | </front> |
---|
1184 | <seriesInfo name='BCP' value='90' /> |
---|
1185 | <seriesInfo name='RFC' value='3864' /> |
---|
1186 | </reference> |
---|
1187 | |
---|
1188 | <reference anchor="RFC4288"> |
---|
1189 | <front> |
---|
1190 | <title>Media Type Specifications and Registration Procedures</title> |
---|
1191 | <author initials="N." surname="Freed" fullname="N. Freed"> |
---|
1192 | <organization>Sun Microsystems</organization> |
---|
1193 | <address> |
---|
1194 | <email>ned.freed@mrochek.com</email> |
---|
1195 | </address> |
---|
1196 | </author> |
---|
1197 | <author initials="J." surname="Klensin" fullname="J. Klensin"> |
---|
1198 | <address> |
---|
1199 | <email>klensin+ietf@jck.com</email> |
---|
1200 | </address> |
---|
1201 | </author> |
---|
1202 | <date year="2005" month="December"/> |
---|
1203 | </front> |
---|
1204 | <seriesInfo name="BCP" value="13"/> |
---|
1205 | <seriesInfo name="RFC" value="4288"/> |
---|
1206 | </reference> |
---|
1207 | |
---|
1208 | <reference anchor='RFC5226'> |
---|
1209 | <front> |
---|
1210 | <title>Guidelines for Writing an IANA Considerations Section in RFCs</title> |
---|
1211 | <author initials='T.' surname='Narten' fullname='T. Narten'> |
---|
1212 | <organization>IBM</organization> |
---|
1213 | <address><email>narten@us.ibm.com</email></address> |
---|
1214 | </author> |
---|
1215 | <author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'> |
---|
1216 | <organization>Google</organization> |
---|
1217 | <address><email>Harald@Alvestrand.no</email></address> |
---|
1218 | </author> |
---|
1219 | <date year='2008' month='May' /> |
---|
1220 | </front> |
---|
1221 | <seriesInfo name='BCP' value='26' /> |
---|
1222 | <seriesInfo name='RFC' value='5226' /> |
---|
1223 | </reference> |
---|
1224 | |
---|
1225 | </references> |
---|
1226 | |
---|
1227 | <section title="Internet Media Type multipart/byteranges" anchor="internet.media.type.multipart.byteranges"> |
---|
1228 | <iref item="Media Type" subitem="multipart/byteranges" primary="true"/> |
---|
1229 | <iref item="multipart/byteranges Media Type" primary="true"/> |
---|
1230 | <t> |
---|
1231 | When an HTTP <x:ref>206 (Partial Content)</x:ref> response message includes the |
---|
1232 | content of multiple ranges (a response to a request for multiple |
---|
1233 | non-overlapping ranges), these are transmitted as a multipart |
---|
1234 | message body (<xref target="RFC2046" x:fmt="," x:sec="5.1"/>). The media type for this purpose is called |
---|
1235 | "multipart/byteranges". The following is to be registered with IANA <xref target="RFC4288"/>. |
---|
1236 | </t> |
---|
1237 | <t> |
---|
1238 | The multipart/byteranges media type includes one or more parts, each |
---|
1239 | with its own <x:ref>Content-Type</x:ref> and <x:ref>Content-Range</x:ref> |
---|
1240 | fields. The required boundary parameter specifies the boundary string used |
---|
1241 | to separate each body-part. |
---|
1242 | </t> |
---|
1243 | <t> |
---|
1244 | <list style="hanging" x:indent="12em"> |
---|
1245 | <t hangText="Type name:"> |
---|
1246 | multipart |
---|
1247 | </t> |
---|
1248 | <t hangText="Subtype name:"> |
---|
1249 | byteranges |
---|
1250 | </t> |
---|
1251 | <t hangText="Required parameters:"> |
---|
1252 | boundary |
---|
1253 | </t> |
---|
1254 | <t hangText="Optional parameters:"> |
---|
1255 | none |
---|
1256 | </t> |
---|
1257 | <t hangText="Encoding considerations:"> |
---|
1258 | only "7bit", "8bit", or "binary" are permitted |
---|
1259 | </t> |
---|
1260 | <t hangText="Security considerations:"> |
---|
1261 | none |
---|
1262 | </t> |
---|
1263 | <t hangText="Interoperability considerations:"> |
---|
1264 | none |
---|
1265 | </t> |
---|
1266 | <t hangText="Published specification:"> |
---|
1267 | This specification (see <xref target="internet.media.type.multipart.byteranges"/>). |
---|
1268 | </t> |
---|
1269 | <t hangText="Applications that use this media type:"> |
---|
1270 | HTTP components supporting multiple ranges in a single request. |
---|
1271 | </t> |
---|
1272 | <t hangText="Additional information:"> |
---|
1273 | <list style="hanging"> |
---|
1274 | <t hangText="Magic number(s):">none</t> |
---|
1275 | <t hangText="File extension(s):">none</t> |
---|
1276 | <t hangText="Macintosh file type code(s):">none</t> |
---|
1277 | </list> |
---|
1278 | </t> |
---|
1279 | <t hangText="Person and email address to contact for further information:"> |
---|
1280 | See Authors Section. |
---|
1281 | </t> |
---|
1282 | <t hangText="Intended usage:"> |
---|
1283 | COMMON |
---|
1284 | </t> |
---|
1285 | <t hangText="Restrictions on usage:"> |
---|
1286 | none |
---|
1287 | </t> |
---|
1288 | <t hangText="Author/Change controller:"> |
---|
1289 | IESG |
---|
1290 | </t> |
---|
1291 | </list> |
---|
1292 | </t> |
---|
1293 | <x:note> |
---|
1294 | <t> |
---|
1295 | &Note; Despite the name "multipart/byteranges" is not limited to the byte ranges only. |
---|
1296 | </t> |
---|
1297 | </x:note> |
---|
1298 | <figure><preamble> |
---|
1299 | For example: |
---|
1300 | </preamble><artwork type="example"> |
---|
1301 | HTTP/1.1 206 Partial Content |
---|
1302 | Date: Wed, 15 Nov 1995 06:25:24 GMT |
---|
1303 | Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT |
---|
1304 | Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES |
---|
1305 | |
---|
1306 | --THIS_STRING_SEPARATES |
---|
1307 | Content-type: application/pdf |
---|
1308 | Content-range: bytes 500-999/8000 |
---|
1309 | |
---|
1310 | ...the first range... |
---|
1311 | --THIS_STRING_SEPARATES |
---|
1312 | Content-type: application/pdf |
---|
1313 | Content-range: bytes 7000-7999/8000 |
---|
1314 | |
---|
1315 | ...the second range |
---|
1316 | --THIS_STRING_SEPARATES-- |
---|
1317 | </artwork></figure> |
---|
1318 | <figure><preamble> |
---|
1319 | Another example, using the "exampleunit" range unit: |
---|
1320 | </preamble> |
---|
1321 | <artwork type="example"> |
---|
1322 | HTTP/1.1 206 Partial Content |
---|
1323 | Date: Tue, 14 Nov 1995 06:25:24 GMT |
---|
1324 | Last-Modified: Tue, 14 July 04:58:08 GMT |
---|
1325 | Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES |
---|
1326 | |
---|
1327 | --THIS_STRING_SEPARATES |
---|
1328 | Content-type: video/example |
---|
1329 | Content-range: exampleunit 1.2-4.3/25 |
---|
1330 | |
---|
1331 | ...the first range... |
---|
1332 | --THIS_STRING_SEPARATES |
---|
1333 | Content-type: video/example |
---|
1334 | Content-range: exampleunit 11.2-14.3/25 |
---|
1335 | |
---|
1336 | ...the second range |
---|
1337 | --THIS_STRING_SEPARATES-- |
---|
1338 | </artwork> |
---|
1339 | </figure> |
---|
1340 | <t> |
---|
1341 | Notes: |
---|
1342 | <list style="numbers"> |
---|
1343 | <t>Additional CRLFs &MAY; precede the first boundary string in the body.</t> |
---|
1344 | |
---|
1345 | <t>Although <xref target="RFC2046"/> permits the boundary string to be |
---|
1346 | quoted, some existing implementations handle a quoted boundary |
---|
1347 | string incorrectly.</t> |
---|
1348 | |
---|
1349 | <t>A number of clients and servers were coded to an early draft |
---|
1350 | of the byteranges specification to use a media type of |
---|
1351 | multipart/x-byteranges<iref item="multipart/x-byteranges Media Type"/><iref item="Media Type" subitem="multipart/x-byteranges"/>, which is almost, but not quite |
---|
1352 | compatible with the version documented in HTTP/1.1.</t> |
---|
1353 | </list> |
---|
1354 | </t> |
---|
1355 | </section> |
---|
1356 | |
---|
1357 | <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616"> |
---|
1358 | <t> |
---|
1359 | Introduce Range Specifier Registry. |
---|
1360 | (<xref target="range.specifier.registry"/>) |
---|
1361 | </t> |
---|
1362 | <t> |
---|
1363 | Clarify that it is not ok to use a weak validator in a <x:ref>206</x:ref> response. |
---|
1364 | (<xref target="status.206"/>) |
---|
1365 | </t> |
---|
1366 | <t> |
---|
1367 | Change ABNF productions for header fields to only define the field value. |
---|
1368 | (<xref target="header.field.definitions"/>) |
---|
1369 | </t> |
---|
1370 | <t> |
---|
1371 | Clarify that multipart/byteranges can consist of a single part. |
---|
1372 | (<xref target="internet.media.type.multipart.byteranges"/>) |
---|
1373 | </t> |
---|
1374 | </section> |
---|
1375 | |
---|
1376 | <section title="Imported ABNF" anchor="imported.abnf"> |
---|
1377 | <x:anchor-alias value="ALPHA"/> |
---|
1378 | <x:anchor-alias value="CHAR"/> |
---|
1379 | <x:anchor-alias value="CR"/> |
---|
1380 | <x:anchor-alias value="DIGIT"/> |
---|
1381 | <x:anchor-alias value="LF"/> |
---|
1382 | <x:anchor-alias value="OCTET"/> |
---|
1383 | <x:anchor-alias value="SP"/> |
---|
1384 | <x:anchor-alias value="VCHAR"/> |
---|
1385 | <x:anchor-alias value="token"/> |
---|
1386 | <x:anchor-alias value="OWS"/> |
---|
1387 | <x:anchor-alias value="HTTP-date"/> |
---|
1388 | <x:anchor-alias value="entity-tag"/> |
---|
1389 | <t> |
---|
1390 | The following core rules are included by |
---|
1391 | reference, as defined in <xref target="RFC5234" x:fmt="of" x:sec="B.1"/>: |
---|
1392 | ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), |
---|
1393 | DIGIT (decimal 0-9), DQUOTE (double quote), |
---|
1394 | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), |
---|
1395 | OCTET (any 8-bit sequence of data), SP (space), and |
---|
1396 | VCHAR (any visible US-ASCII character). |
---|
1397 | </t> |
---|
1398 | <t> |
---|
1399 | Note that all rules derived from <x:ref>token</x:ref> are to |
---|
1400 | be compared case-insensitively, like <x:ref>range-unit</x:ref> and |
---|
1401 | <x:ref>acceptable-ranges</x:ref>. |
---|
1402 | </t> |
---|
1403 | <t> |
---|
1404 | The rules below are defined in <xref target="Part1"/>: |
---|
1405 | </t> |
---|
1406 | <figure><artwork type="abnf2616"> |
---|
1407 | <x:ref>OWS</x:ref> = <OWS, defined in &whitespace;> |
---|
1408 | <x:ref>token</x:ref> = <token, defined in &field-components;> |
---|
1409 | </artwork></figure> |
---|
1410 | <t> |
---|
1411 | The rules below are defined in other parts: |
---|
1412 | </t> |
---|
1413 | <figure><artwork type="abnf2616"> |
---|
1414 | <x:ref>HTTP-date</x:ref> = <HTTP-date, defined in &http-date;> |
---|
1415 | <x:ref>entity-tag</x:ref> = <entity-tag, defined in &entity-tags;> |
---|
1416 | </artwork></figure> |
---|
1417 | </section> |
---|
1418 | |
---|
1419 | <?BEGININC p5-range.abnf-appendix ?> |
---|
1420 | <section xmlns:x="http://purl.org/net/xml2rfc/ext" title="Collected ABNF" anchor="collected.abnf"> |
---|
1421 | <figure> |
---|
1422 | <artwork type="abnf" name="p5-range.parsed-abnf"> |
---|
1423 | <x:ref>Accept-Ranges</x:ref> = acceptable-ranges |
---|
1424 | |
---|
1425 | <x:ref>Content-Range</x:ref> = byte-content-range-spec / other-content-range-spec |
---|
1426 | |
---|
1427 | <x:ref>HTTP-date</x:ref> = <HTTP-date, defined in [Part2], Section 5.1> |
---|
1428 | |
---|
1429 | <x:ref>If-Range</x:ref> = entity-tag / HTTP-date |
---|
1430 | |
---|
1431 | <x:ref>OWS</x:ref> = <OWS, defined in [Part1], Section 3.2.1> |
---|
1432 | |
---|
1433 | <x:ref>Range</x:ref> = byte-ranges-specifier / other-ranges-specifier |
---|
1434 | |
---|
1435 | <x:ref>acceptable-ranges</x:ref> = ( *( "," OWS ) range-unit *( OWS "," [ OWS |
---|
1436 | range-unit ] ) ) / "none" |
---|
1437 | |
---|
1438 | <x:ref>byte-content-range-spec</x:ref> = bytes-unit SP byte-range-resp-spec "/" ( |
---|
1439 | instance-length / "*" ) |
---|
1440 | <x:ref>byte-range-resp-spec</x:ref> = ( first-byte-pos "-" last-byte-pos ) / "*" |
---|
1441 | <x:ref>byte-range-set</x:ref> = *( "," OWS ) ( byte-range-spec / |
---|
1442 | suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec / |
---|
1443 | suffix-byte-range-spec ) ] ) |
---|
1444 | <x:ref>byte-range-spec</x:ref> = first-byte-pos "-" [ last-byte-pos ] |
---|
1445 | <x:ref>byte-ranges-specifier</x:ref> = bytes-unit "=" byte-range-set |
---|
1446 | <x:ref>bytes-unit</x:ref> = "bytes" |
---|
1447 | |
---|
1448 | <x:ref>entity-tag</x:ref> = <entity-tag, defined in [Part4], Section 2.3> |
---|
1449 | |
---|
1450 | <x:ref>first-byte-pos</x:ref> = 1*DIGIT |
---|
1451 | |
---|
1452 | <x:ref>instance-length</x:ref> = 1*DIGIT |
---|
1453 | |
---|
1454 | <x:ref>last-byte-pos</x:ref> = 1*DIGIT |
---|
1455 | |
---|
1456 | <x:ref>other-content-range-spec</x:ref> = other-range-unit SP other-range-resp-spec |
---|
1457 | <x:ref>other-range-resp-spec</x:ref> = *CHAR |
---|
1458 | <x:ref>other-range-set</x:ref> = 1*CHAR |
---|
1459 | <x:ref>other-range-unit</x:ref> = token |
---|
1460 | <x:ref>other-ranges-specifier</x:ref> = other-range-unit "=" other-range-set |
---|
1461 | |
---|
1462 | <x:ref>range-unit</x:ref> = bytes-unit / other-range-unit |
---|
1463 | |
---|
1464 | <x:ref>suffix-byte-range-spec</x:ref> = "-" suffix-length |
---|
1465 | <x:ref>suffix-length</x:ref> = 1*DIGIT |
---|
1466 | |
---|
1467 | <x:ref>token</x:ref> = <token, defined in [Part1], Section 3.2.4> |
---|
1468 | </artwork> |
---|
1469 | </figure> |
---|
1470 | </section> |
---|
1471 | <?ENDINC p5-range.abnf-appendix ?> |
---|
1472 | |
---|
1473 | |
---|
1474 | <section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log"> |
---|
1475 | <t> |
---|
1476 | Changes up to the first Working Group Last Call draft are summarized |
---|
1477 | in <eref target="http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-19#appendix-D"/>. |
---|
1478 | </t> |
---|
1479 | |
---|
1480 | <section title="Since draft-ietf-httpbis-p5-range-19" anchor="changes.since.19"> |
---|
1481 | <t> |
---|
1482 | Closed issues: |
---|
1483 | <list style="symbols"> |
---|
1484 | <t> |
---|
1485 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/358"/>: |
---|
1486 | "ABNF list expansion code problem" |
---|
1487 | </t> |
---|
1488 | <t> |
---|
1489 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/361"/>: |
---|
1490 | "ABNF requirements for recipients" |
---|
1491 | </t> |
---|
1492 | <t> |
---|
1493 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/367"/>: |
---|
1494 | "reserve 'none' as byte range unit" |
---|
1495 | </t> |
---|
1496 | <t> |
---|
1497 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/368"/>: |
---|
1498 | "note introduction of new IANA registries as normative changes" |
---|
1499 | </t> |
---|
1500 | <t> |
---|
1501 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/369"/>: |
---|
1502 | "range units vs leading zeroes vs size" |
---|
1503 | </t> |
---|
1504 | </list> |
---|
1505 | </t> |
---|
1506 | </section> |
---|
1507 | |
---|
1508 | </section> |
---|
1509 | |
---|
1510 | </back> |
---|
1511 | </rfc> |
---|