1 | <?xml version="1.0" encoding="UTF-8"?> |
---|
2 | <!-- |
---|
3 | This XML document is the output of clean-for-DTD.xslt; a tool that strips |
---|
4 | extensions to RFC2629(bis) from documents for processing with xml2rfc. |
---|
5 | --> |
---|
6 | <?rfc toc="yes" ?> |
---|
7 | <?rfc symrefs="yes" ?> |
---|
8 | <?rfc sortrefs="yes" ?> |
---|
9 | <?rfc compact="yes"?> |
---|
10 | <?rfc subcompact="no" ?> |
---|
11 | <?rfc linkmailto="no" ?> |
---|
12 | <?rfc editing="no" ?> |
---|
13 | <!DOCTYPE rfc |
---|
14 | PUBLIC "" "rfc2629.dtd"> |
---|
15 | <rfc obsoletes="2068, 2616" category="std" ipr="full3978" docName="draft-ietf-httpbis-p5-range-00"> |
---|
16 | <front> |
---|
17 | |
---|
18 | <title abbrev="HTTP/1.1">HTTP/1.1, part 5: Range Requests and Partial Responses</title> |
---|
19 | |
---|
20 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
21 | <organization abbrev="Day Software">Day Software</organization> |
---|
22 | <address> |
---|
23 | <postal> |
---|
24 | <street>23 Corporate Plaza DR, Suite 280</street> |
---|
25 | <city>Newport Beach</city> |
---|
26 | <region>CA</region> |
---|
27 | <code>92660</code> |
---|
28 | <country>USA</country> |
---|
29 | </postal> |
---|
30 | <phone>+1-949-706-5300</phone> |
---|
31 | <facsimile>+1-949-706-5305</facsimile> |
---|
32 | <email>fielding@gbiv.com</email> |
---|
33 | <uri>http://roy.gbiv.com/</uri> |
---|
34 | </address> |
---|
35 | </author> |
---|
36 | |
---|
37 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
38 | <organization>One Laptop per Child</organization> |
---|
39 | <address> |
---|
40 | <postal> |
---|
41 | <street>21 Oak Knoll Road</street> |
---|
42 | <city>Carlisle</city> |
---|
43 | <region>MA</region> |
---|
44 | <code>01741</code> |
---|
45 | <country>USA</country> |
---|
46 | </postal> |
---|
47 | <email>jg@laptop.org</email> |
---|
48 | <uri>http://www.laptop.org/</uri> |
---|
49 | </address> |
---|
50 | </author> |
---|
51 | |
---|
52 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
53 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
54 | <address> |
---|
55 | <postal> |
---|
56 | <street>HP Labs, Large Scale Systems Group</street> |
---|
57 | <street>1501 Page Mill Road, MS 1177</street> |
---|
58 | <city>Palo Alto</city> |
---|
59 | <region>CA</region> |
---|
60 | <code>94304</code> |
---|
61 | <country>USA</country> |
---|
62 | </postal> |
---|
63 | <email>JeffMogul@acm.org</email> |
---|
64 | </address> |
---|
65 | </author> |
---|
66 | |
---|
67 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
68 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
69 | <address> |
---|
70 | <postal> |
---|
71 | <street>1 Microsoft Way</street> |
---|
72 | <city>Redmond</city> |
---|
73 | <region>WA</region> |
---|
74 | <code>98052</code> |
---|
75 | <country>USA</country> |
---|
76 | </postal> |
---|
77 | <email>henrikn@microsoft.com</email> |
---|
78 | </address> |
---|
79 | </author> |
---|
80 | |
---|
81 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
82 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
83 | <address> |
---|
84 | <postal> |
---|
85 | <street>345 Park Ave</street> |
---|
86 | <city>San Jose</city> |
---|
87 | <region>CA</region> |
---|
88 | <code>95110</code> |
---|
89 | <country>USA</country> |
---|
90 | </postal> |
---|
91 | <email>LMM@acm.org</email> |
---|
92 | <uri>http://larry.masinter.net/</uri> |
---|
93 | </address> |
---|
94 | </author> |
---|
95 | |
---|
96 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
97 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
98 | <address> |
---|
99 | <postal> |
---|
100 | <street>1 Microsoft Way</street> |
---|
101 | <city>Redmond</city> |
---|
102 | <region>WA</region> |
---|
103 | <code>98052</code> |
---|
104 | </postal> |
---|
105 | <email>paulle@microsoft.com</email> |
---|
106 | </address> |
---|
107 | </author> |
---|
108 | |
---|
109 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
110 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
111 | <address> |
---|
112 | <postal> |
---|
113 | <street>MIT Computer Science and Artificial Intelligence Laboratory</street> |
---|
114 | <street>The Stata Center, Building 32</street> |
---|
115 | <street>32 Vassar Street</street> |
---|
116 | <city>Cambridge</city> |
---|
117 | <region>MA</region> |
---|
118 | <code>02139</code> |
---|
119 | <country>USA</country> |
---|
120 | </postal> |
---|
121 | <email>timbl@w3.org</email> |
---|
122 | <uri>http://www.w3.org/People/Berners-Lee/</uri> |
---|
123 | </address> |
---|
124 | </author> |
---|
125 | |
---|
126 | <date month="December" year="2007"/> |
---|
127 | |
---|
128 | <abstract> |
---|
129 | <t> |
---|
130 | The Hypertext Transfer Protocol (HTTP) is an application-level |
---|
131 | protocol for distributed, collaborative, hypermedia information |
---|
132 | systems. HTTP has been in use by the World Wide Web global information |
---|
133 | initiative since 1990. This document is Part 5 of the seven-part specification |
---|
134 | that defines the protocol referred to as "HTTP/1.1" and, taken together, |
---|
135 | obsoletes RFC 2616. Part 5 defines range-specific requests and |
---|
136 | the rules for constructing and combining responses to those requests. |
---|
137 | </t> |
---|
138 | </abstract> |
---|
139 | |
---|
140 | <note title="Editorial Note (To be removed by RFC Editor)"> |
---|
141 | <t> |
---|
142 | This version of the HTTP specification contains only minimal editorial |
---|
143 | changes from <xref target="RFC2616"/> (abstract, introductory paragraph, |
---|
144 | and authors' addresses). All other changes are due to partitioning the |
---|
145 | original into seven mostly independent parts. The intent is for readers |
---|
146 | of future drafts to able to use draft 00 as the basis for comparison |
---|
147 | when the WG makes later changes to the specification text. This draft |
---|
148 | will shortly be followed by draft 01 (containing the first round of changes |
---|
149 | that have already been agreed to on the mailing list). There is no point in |
---|
150 | reviewing this draft other than to verify that the partitioning has been |
---|
151 | done correctly. Roy T. Fielding, Yves Lafon, and Julian Reschke |
---|
152 | will be the editors after draft 00 is submitted. |
---|
153 | </t> |
---|
154 | <t> |
---|
155 | Discussion of this draft should take place on the HTTPBIS working group |
---|
156 | mailing list (ietf-http-wg@w3.org). The current issues list is |
---|
157 | at <eref target="http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/"/> |
---|
158 | and related documents (including fancy diffs) can be found at |
---|
159 | <eref target="http://www3.tools.ietf.org/wg/httpbis/"/>. |
---|
160 | </t> |
---|
161 | </note> |
---|
162 | </front> |
---|
163 | <middle> |
---|
164 | <section title="Introduction" anchor="introduction"> |
---|
165 | <t> |
---|
166 | This document will define aspects of HTTP related to range requests, |
---|
167 | partial responses, and the multipart/byteranges media type. Right now |
---|
168 | it only includes the extracted relevant sections of |
---|
169 | <xref target="RFC2616">RFC 2616</xref> without edit. |
---|
170 | </t> |
---|
171 | </section> |
---|
172 | |
---|
173 | <section title="Range Units" anchor="range.units"> |
---|
174 | <t> |
---|
175 | HTTP/1.1 allows a client to request that only part (a range of) the |
---|
176 | response entity be included within the response. HTTP/1.1 uses range |
---|
177 | units in the Range (<xref target="header.range"/>) and Content-Range (<xref target="header.content-range"/>) |
---|
178 | header fields. An entity can be broken down into subranges according |
---|
179 | to various structural units. |
---|
180 | </t> |
---|
181 | <figure><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"/><artwork type="abnf2616"><![CDATA[ |
---|
182 | range-unit = bytes-unit | other-range-unit |
---|
183 | bytes-unit = "bytes" |
---|
184 | other-range-unit = token |
---|
185 | ]]></artwork></figure> |
---|
186 | <t> |
---|
187 | The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 |
---|
188 | implementations MAY ignore ranges specified using other units. |
---|
189 | </t> |
---|
190 | <t> |
---|
191 | HTTP/1.1 has been designed to allow implementations of applications |
---|
192 | that do not depend on knowledge of ranges. |
---|
193 | </t> |
---|
194 | </section> |
---|
195 | |
---|
196 | <section title="Status Code Definitions"> |
---|
197 | <section title="206 Partial Content" anchor="status.206"> |
---|
198 | <iref primary="true" item="206 Partial Content (status code)"/> |
---|
199 | <iref primary="true" item="Status Codes" subitem="206 Partial Content"/> |
---|
200 | <t> |
---|
201 | The server has fulfilled the partial GET request for the resource. |
---|
202 | The request MUST have included a Range header field (<xref target="header.range"/>) |
---|
203 | indicating the desired range, and MAY have included an If-Range |
---|
204 | header field (<xref target="header.if-range"/>) to make the request conditional. |
---|
205 | </t> |
---|
206 | <t> |
---|
207 | The response MUST include the following header fields: |
---|
208 | <list style="symbols"> |
---|
209 | <t> |
---|
210 | Either a Content-Range header field (<xref target="header.content-range"/>) indicating |
---|
211 | the range included with this response, or a multipart/byteranges |
---|
212 | Content-Type including Content-Range fields for each part. If a |
---|
213 | Content-Length header field is present in the response, its |
---|
214 | value MUST match the actual number of OCTETs transmitted in the |
---|
215 | message-body. |
---|
216 | </t> |
---|
217 | <t> |
---|
218 | Date |
---|
219 | </t> |
---|
220 | <t> |
---|
221 | ETag and/or Content-Location, if the header would have been sent |
---|
222 | in a 200 response to the same request |
---|
223 | </t> |
---|
224 | <t> |
---|
225 | Expires, Cache-Control, and/or Vary, if the field-value might |
---|
226 | differ from that sent in any previous response for the same |
---|
227 | variant |
---|
228 | </t> |
---|
229 | </list> |
---|
230 | </t> |
---|
231 | <t> |
---|
232 | If the 206 response is the result of an If-Range request that used a |
---|
233 | strong cache validator (see Section 4 of <xref target="Part4"/>), the response SHOULD NOT |
---|
234 | include other entity-headers. If the response is the result of an |
---|
235 | If-Range request that used a weak validator, the response MUST NOT |
---|
236 | include other entity-headers; this prevents inconsistencies between |
---|
237 | cached entity-bodies and updated headers. Otherwise, the response |
---|
238 | MUST include all of the entity-headers that would have been returned |
---|
239 | with a 200 (OK) response to the same request. |
---|
240 | </t> |
---|
241 | <t> |
---|
242 | A cache MUST NOT combine a 206 response with other previously cached |
---|
243 | content if the ETag or Last-Modified headers do not match exactly, |
---|
244 | see <xref target="combining.byte.ranges" format="counter"/>. |
---|
245 | </t> |
---|
246 | <t> |
---|
247 | A cache that does not support the Range and Content-Range headers |
---|
248 | MUST NOT cache 206 (Partial) responses. |
---|
249 | </t> |
---|
250 | </section> |
---|
251 | |
---|
252 | <section title="416 Requested Range Not Satisfiable" anchor="status.416"> |
---|
253 | <iref primary="true" item="416 Requested Range Not Satisfiable (status code)"/> |
---|
254 | <iref primary="true" item="Status Codes" subitem="416 Requested Range Not Satisfiable"/> |
---|
255 | <t> |
---|
256 | A server SHOULD return a response with this status code if a request |
---|
257 | included a Range request-header field (<xref target="header.range"/>), and none of |
---|
258 | the range-specifier values in this field overlap the current extent |
---|
259 | of the selected resource, and the request did not include an If-Range |
---|
260 | request-header field. (For byte-ranges, this means that the first-byte-pos |
---|
261 | of all of the byte-range-spec values were greater than the |
---|
262 | current length of the selected resource.) |
---|
263 | </t> |
---|
264 | <t> |
---|
265 | When this status code is returned for a byte-range request, the |
---|
266 | response SHOULD include a Content-Range entity-header field |
---|
267 | specifying the current length of the selected resource (see <xref target="header.content-range"/>). |
---|
268 | This response MUST NOT use the multipart/byteranges content-type. |
---|
269 | </t> |
---|
270 | </section> |
---|
271 | </section> |
---|
272 | |
---|
273 | <section title="Combining Byte Ranges" anchor="combining.byte.ranges"> |
---|
274 | <t> |
---|
275 | A response might transfer only a subrange of the bytes of an entity-body, |
---|
276 | either because the request included one or more Range |
---|
277 | specifications, or because a connection was broken prematurely. After |
---|
278 | several such transfers, a cache might have received several ranges of |
---|
279 | the same entity-body. |
---|
280 | </t> |
---|
281 | <t> |
---|
282 | If a cache has a stored non-empty set of subranges for an entity, and |
---|
283 | an incoming response transfers another subrange, the cache MAY |
---|
284 | combine the new subrange with the existing set if both the following |
---|
285 | conditions are met: |
---|
286 | <list style="symbols"> |
---|
287 | <t>Both the incoming response and the cache entry have a cache |
---|
288 | validator.</t> |
---|
289 | <t>The two cache validators match using the strong comparison |
---|
290 | function (see Section 4 of <xref target="Part4"/>).</t> |
---|
291 | </list> |
---|
292 | </t> |
---|
293 | <t> |
---|
294 | If either requirement is not met, the cache MUST use only the most |
---|
295 | recent partial response (based on the Date values transmitted with |
---|
296 | every response, and using the incoming response if these values are |
---|
297 | equal or missing), and MUST discard the other partial information. |
---|
298 | </t> |
---|
299 | </section> |
---|
300 | |
---|
301 | <section title="Header Field Definitions" anchor="header.fields"> |
---|
302 | <t> |
---|
303 | This section defines the syntax and semantics of all standard |
---|
304 | HTTP/1.1 header fields. For entity-header fields, both sender and |
---|
305 | recipient refer to either the client or the server, depending on who |
---|
306 | sends and who receives the entity. |
---|
307 | </t> |
---|
308 | <section title="Accept-Ranges" anchor="header.accept-ranges"> |
---|
309 | <iref primary="true" item="Accept-Ranges header"/> |
---|
310 | <iref primary="true" item="Headers" subitem="Accept-Ranges"/> |
---|
311 | <t> |
---|
312 | The Accept-Ranges response-header field allows the server to |
---|
313 | indicate its acceptance of range requests for a resource: |
---|
314 | </t> |
---|
315 | <figure><iref primary="true" item="Grammar" subitem="Accept-Ranges"/><iref primary="true" item="Grammar" subitem="acceptable-ranges"/><artwork type="abnf2616"><![CDATA[ |
---|
316 | Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges |
---|
317 | acceptable-ranges = 1#range-unit | "none" |
---|
318 | ]]></artwork></figure> |
---|
319 | <t> |
---|
320 | Origin servers that accept byte-range requests MAY send |
---|
321 | </t> |
---|
322 | <figure><artwork type="example"><![CDATA[ |
---|
323 | Accept-Ranges: bytes |
---|
324 | ]]></artwork></figure> |
---|
325 | <t> |
---|
326 | but are not required to do so. Clients MAY generate byte-range |
---|
327 | requests without having received this header for the resource |
---|
328 | involved. Range units are defined in <xref target="range.units"/>. |
---|
329 | </t> |
---|
330 | <t> |
---|
331 | Servers that do not accept any kind of range request for a |
---|
332 | resource MAY send |
---|
333 | </t> |
---|
334 | <figure><artwork type="example"><![CDATA[ |
---|
335 | Accept-Ranges: none |
---|
336 | ]]></artwork></figure> |
---|
337 | <t> |
---|
338 | to advise the client not to attempt a range request. |
---|
339 | </t> |
---|
340 | </section> |
---|
341 | |
---|
342 | <section title="Content-Range" anchor="header.content-range"> |
---|
343 | <iref primary="true" item="Content-Range header"/> |
---|
344 | <iref primary="true" item="Headers" subitem="Content-Range"/> |
---|
345 | <t> |
---|
346 | The Content-Range entity-header is sent with a partial entity-body to |
---|
347 | specify where in the full entity-body the partial body should be |
---|
348 | applied. Range units are defined in <xref target="range.units"/>. |
---|
349 | </t> |
---|
350 | <figure><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"/><artwork type="abnf2616"><![CDATA[ |
---|
351 | Content-Range = "Content-Range" ":" content-range-spec |
---|
352 | |
---|
353 | content-range-spec = byte-content-range-spec |
---|
354 | byte-content-range-spec = bytes-unit SP |
---|
355 | byte-range-resp-spec "/" |
---|
356 | ( instance-length | "*" ) |
---|
357 | |
---|
358 | byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) |
---|
359 | | "*" |
---|
360 | instance-length = 1*DIGIT |
---|
361 | ]]></artwork></figure> |
---|
362 | <t> |
---|
363 | The header SHOULD indicate the total length of the full entity-body, |
---|
364 | unless this length is unknown or difficult to determine. The asterisk |
---|
365 | "*" character means that the instance-length is unknown at the time |
---|
366 | when the response was generated. |
---|
367 | </t> |
---|
368 | <t> |
---|
369 | Unlike byte-ranges-specifier values (see <xref target="byte.ranges"/>), a byte-range-resp-spec |
---|
370 | MUST only specify one range, and MUST contain |
---|
371 | absolute byte positions for both the first and last byte of the |
---|
372 | range. |
---|
373 | </t> |
---|
374 | <t> |
---|
375 | A byte-content-range-spec with a byte-range-resp-spec whose last-byte-pos |
---|
376 | value is less than its first-byte-pos value, or whose |
---|
377 | instance-length value is less than or equal to its last-byte-pos |
---|
378 | value, is invalid. The recipient of an invalid byte-content-range-spec |
---|
379 | MUST ignore it and any content transferred along with it. |
---|
380 | </t> |
---|
381 | <t> |
---|
382 | A server sending a response with status code 416 (Requested range not |
---|
383 | satisfiable) SHOULD include a Content-Range field with a byte-range-resp-spec |
---|
384 | of "*". The instance-length specifies the current length of |
---|
385 | the selected resource. A response with status code 206 (Partial |
---|
386 | Content) MUST NOT include a Content-Range field with a byte-range-resp-spec of "*". |
---|
387 | </t> |
---|
388 | <t> |
---|
389 | Examples of byte-content-range-spec values, assuming that the entity |
---|
390 | contains a total of 1234 bytes: |
---|
391 | <list style="symbols"> |
---|
392 | <t> |
---|
393 | The first 500 bytes: |
---|
394 | <figure><artwork type="text/plain"><![CDATA[ |
---|
395 | bytes 0-499/1234 |
---|
396 | ]]></artwork></figure> |
---|
397 | </t> |
---|
398 | <t> |
---|
399 | The second 500 bytes: |
---|
400 | <figure><artwork type="text/plain"><![CDATA[ |
---|
401 | bytes 500-999/1234 |
---|
402 | ]]></artwork></figure> |
---|
403 | </t> |
---|
404 | <t> |
---|
405 | All except for the first 500 bytes: |
---|
406 | <figure><artwork type="text/plain"><![CDATA[ |
---|
407 | bytes 500-1233/1234 |
---|
408 | ]]></artwork></figure> |
---|
409 | </t> |
---|
410 | <t> |
---|
411 | The last 500 bytes: |
---|
412 | <figure><artwork type="text/plain"><![CDATA[ |
---|
413 | bytes 734-1233/1234 |
---|
414 | ]]></artwork></figure> |
---|
415 | </t> |
---|
416 | </list> |
---|
417 | </t> |
---|
418 | <t> |
---|
419 | When an HTTP message includes the content of a single range (for |
---|
420 | example, a response to a request for a single range, or to a request |
---|
421 | for a set of ranges that overlap without any holes), this content is |
---|
422 | transmitted with a Content-Range header, and a Content-Length header |
---|
423 | showing the number of bytes actually transferred. For example, |
---|
424 | </t> |
---|
425 | <figure><artwork type="example"><![CDATA[ |
---|
426 | HTTP/1.1 206 Partial content |
---|
427 | Date: Wed, 15 Nov 1995 06:25:24 GMT |
---|
428 | Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT |
---|
429 | Content-Range: bytes 21010-47021/47022 |
---|
430 | Content-Length: 26012 |
---|
431 | Content-Type: image/gif |
---|
432 | ]]></artwork></figure> |
---|
433 | <t> |
---|
434 | When an HTTP message includes the content of multiple ranges (for |
---|
435 | example, a response to a request for multiple non-overlapping |
---|
436 | ranges), these are transmitted as a multipart message. The multipart |
---|
437 | media type used for this purpose is "multipart/byteranges" as defined |
---|
438 | in <xref target="internet.media.type.multipart.byteranges"/>. See <xref target="changes.from.rfc.2068"/> for a compatibility issue. |
---|
439 | </t> |
---|
440 | <t> |
---|
441 | A response to a request for a single range MUST NOT be sent using the |
---|
442 | multipart/byteranges media type. A response to a request for |
---|
443 | multiple ranges, whose result is a single range, MAY be sent as a |
---|
444 | multipart/byteranges media type with one part. A client that cannot |
---|
445 | decode a multipart/byteranges message MUST NOT ask for multiple |
---|
446 | byte-ranges in a single request. |
---|
447 | </t> |
---|
448 | <t> |
---|
449 | When a client requests multiple byte-ranges in one request, the |
---|
450 | server SHOULD return them in the order that they appeared in the |
---|
451 | request. |
---|
452 | </t> |
---|
453 | <t> |
---|
454 | If the server ignores a byte-range-spec because it is syntactically |
---|
455 | invalid, the server SHOULD treat the request as if the invalid Range |
---|
456 | header field did not exist. (Normally, this means return a 200 |
---|
457 | response containing the full entity). |
---|
458 | </t> |
---|
459 | <t> |
---|
460 | If the server receives a request (other than one including an If-Range |
---|
461 | request-header field) with an unsatisfiable Range request-header |
---|
462 | field (that is, all of whose byte-range-spec values have a |
---|
463 | first-byte-pos value greater than the current length of the selected |
---|
464 | resource), it SHOULD return a response code of 416 (Requested range |
---|
465 | not satisfiable) (<xref target="status.416"/>). |
---|
466 | <list><t> |
---|
467 | Note: clients cannot depend on servers to send a 416 (Requested |
---|
468 | range not satisfiable) response instead of a 200 (OK) response for |
---|
469 | an unsatisfiable Range request-header, since not all servers |
---|
470 | implement this request-header. |
---|
471 | </t></list> |
---|
472 | </t> |
---|
473 | </section> |
---|
474 | |
---|
475 | <section title="If-Range" anchor="header.if-range"> |
---|
476 | <iref primary="true" item="If-Range header"/> |
---|
477 | <iref primary="true" item="Headers" subitem="If-Range"/> |
---|
478 | <t> |
---|
479 | If a client has a partial copy of an entity in its cache, and wishes |
---|
480 | to have an up-to-date copy of the entire entity in its cache, it |
---|
481 | could use the Range request-header with a conditional GET (using |
---|
482 | either or both of If-Unmodified-Since and If-Match.) However, if the |
---|
483 | condition fails because the entity has been modified, the client |
---|
484 | would then have to make a second request to obtain the entire current |
---|
485 | entity-body. |
---|
486 | </t> |
---|
487 | <t> |
---|
488 | The If-Range header allows a client to "short-circuit" the second |
---|
489 | request. Informally, its meaning is `if the entity is unchanged, send |
---|
490 | me the part(s) that I am missing; otherwise, send me the entire new |
---|
491 | entity'. |
---|
492 | </t> |
---|
493 | <figure><iref primary="true" item="Grammar" subitem="If-Range"/><artwork type="abnf2616"><![CDATA[ |
---|
494 | If-Range = "If-Range" ":" ( entity-tag | HTTP-date ) |
---|
495 | ]]></artwork></figure> |
---|
496 | <t> |
---|
497 | If the client has no entity tag for an entity, but does have a Last-Modified |
---|
498 | date, it MAY use that date in an If-Range header. (The |
---|
499 | server can distinguish between a valid HTTP-date and any form of |
---|
500 | entity-tag by examining no more than two characters.) The If-Range |
---|
501 | header SHOULD only be used together with a Range header, and MUST be |
---|
502 | ignored if the request does not include a Range header, or if the |
---|
503 | server does not support the sub-range operation. |
---|
504 | </t> |
---|
505 | <t> |
---|
506 | If the entity tag given in the If-Range header matches the current |
---|
507 | entity tag for the entity, then the server SHOULD provide the |
---|
508 | specified sub-range of the entity using a 206 (Partial content) |
---|
509 | response. If the entity tag does not match, then the server SHOULD |
---|
510 | return the entire entity using a 200 (OK) response. |
---|
511 | </t> |
---|
512 | </section> |
---|
513 | |
---|
514 | <section title="Range" anchor="header.range"> |
---|
515 | <iref primary="true" item="Range header"/> |
---|
516 | <iref primary="true" item="Headers" subitem="Range"/> |
---|
517 | |
---|
518 | <section title="Byte Ranges" anchor="byte.ranges"> |
---|
519 | <t> |
---|
520 | Since all HTTP entities are represented in HTTP messages as sequences |
---|
521 | of bytes, the concept of a byte range is meaningful for any HTTP |
---|
522 | entity. (However, not all clients and servers need to support byte-range |
---|
523 | operations.) |
---|
524 | </t> |
---|
525 | <t> |
---|
526 | Byte range specifications in HTTP apply to the sequence of bytes in |
---|
527 | the entity-body (not necessarily the same as the message-body). |
---|
528 | </t> |
---|
529 | <t> |
---|
530 | A byte range operation MAY specify a single range of bytes, or a set |
---|
531 | of ranges within a single entity. |
---|
532 | </t> |
---|
533 | <figure><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"/><artwork type="abnf2616"><![CDATA[ |
---|
534 | ranges-specifier = byte-ranges-specifier |
---|
535 | byte-ranges-specifier = bytes-unit "=" byte-range-set |
---|
536 | byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec ) |
---|
537 | byte-range-spec = first-byte-pos "-" [last-byte-pos] |
---|
538 | first-byte-pos = 1*DIGIT |
---|
539 | last-byte-pos = 1*DIGIT |
---|
540 | ]]></artwork></figure> |
---|
541 | <t> |
---|
542 | The first-byte-pos value in a byte-range-spec gives the byte-offset |
---|
543 | of the first byte in a range. The last-byte-pos value gives the |
---|
544 | byte-offset of the last byte in the range; that is, the byte |
---|
545 | positions specified are inclusive. Byte offsets start at zero. |
---|
546 | </t> |
---|
547 | <t> |
---|
548 | If the last-byte-pos value is present, it MUST be greater than or |
---|
549 | equal to the first-byte-pos in that byte-range-spec, or the byte-range-spec |
---|
550 | is syntactically invalid. The recipient of a byte-range-set |
---|
551 | that includes one or more syntactically invalid byte-range-spec |
---|
552 | values MUST ignore the header field that includes that byte-range-set. |
---|
553 | </t> |
---|
554 | <t> |
---|
555 | If the last-byte-pos value is absent, or if the value is greater than |
---|
556 | or equal to the current length of the entity-body, last-byte-pos is |
---|
557 | taken to be equal to one less than the current length of the entity-body |
---|
558 | in bytes. |
---|
559 | </t> |
---|
560 | <t> |
---|
561 | By its choice of last-byte-pos, a client can limit the number of |
---|
562 | bytes retrieved without knowing the size of the entity. |
---|
563 | </t> |
---|
564 | <figure><iref primary="true" item="Grammar" subitem="suffix-byte-range-spec"/><iref primary="true" item="Grammar" subitem="suffix-length"/><artwork type="abnf2616"><![CDATA[ |
---|
565 | suffix-byte-range-spec = "-" suffix-length |
---|
566 | suffix-length = 1*DIGIT |
---|
567 | ]]></artwork></figure> |
---|
568 | <t> |
---|
569 | A suffix-byte-range-spec is used to specify the suffix of the |
---|
570 | entity-body, of a length given by the suffix-length value. (That is, |
---|
571 | this form specifies the last N bytes of an entity-body.) If the |
---|
572 | entity is shorter than the specified suffix-length, the entire |
---|
573 | entity-body is used. |
---|
574 | </t> |
---|
575 | <t> |
---|
576 | If a syntactically valid byte-range-set includes at least one byte-range-spec |
---|
577 | whose first-byte-pos is less than the current length of |
---|
578 | the entity-body, or at least one suffix-byte-range-spec with a non-zero |
---|
579 | suffix-length, then the byte-range-set is satisfiable. |
---|
580 | Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set |
---|
581 | is unsatisfiable, the server SHOULD return a response with a status |
---|
582 | of 416 (Requested range not satisfiable). Otherwise, the server |
---|
583 | SHOULD return a response with a status of 206 (Partial Content) |
---|
584 | containing the satisfiable ranges of the entity-body. |
---|
585 | </t> |
---|
586 | <t> |
---|
587 | Examples of byte-ranges-specifier values (assuming an entity-body of |
---|
588 | length 10000): |
---|
589 | <list style="symbols"> |
---|
590 | <t>The first 500 bytes (byte offsets 0-499, inclusive): bytes=0-499</t> |
---|
591 | |
---|
592 | <t>The second 500 bytes (byte offsets 500-999, inclusive): |
---|
593 | bytes=500-999</t> |
---|
594 | |
---|
595 | <t>The final 500 bytes (byte offsets 9500-9999, inclusive): |
---|
596 | bytes=-500</t> |
---|
597 | |
---|
598 | <t>Or bytes=9500-</t> |
---|
599 | |
---|
600 | <t>The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1</t> |
---|
601 | |
---|
602 | <t>Several legal but not canonical specifications of the second 500 |
---|
603 | bytes (byte offsets 500-999, inclusive): |
---|
604 | <vspace/> |
---|
605 | bytes=500-600,601-999<vspace/> |
---|
606 | bytes=500-700,601-999</t> |
---|
607 | </list> |
---|
608 | </t> |
---|
609 | </section> |
---|
610 | |
---|
611 | <section title="Range Retrieval Requests" anchor="range.retrieval.requests"> |
---|
612 | <t> |
---|
613 | HTTP retrieval requests using conditional or unconditional GET |
---|
614 | methods MAY request one or more sub-ranges of the entity, instead of |
---|
615 | the entire entity, using the Range request header, which applies to |
---|
616 | the entity returned as the result of the request: |
---|
617 | </t> |
---|
618 | <figure><iref primary="true" item="Grammar" subitem="Range"/><artwork type="abnf2616"><![CDATA[ |
---|
619 | Range = "Range" ":" ranges-specifier |
---|
620 | ]]></artwork></figure> |
---|
621 | <t> |
---|
622 | A server MAY ignore the Range header. However, HTTP/1.1 origin |
---|
623 | servers and intermediate caches ought to support byte ranges when |
---|
624 | possible, since Range supports efficient recovery from partially |
---|
625 | failed transfers, and supports efficient partial retrieval of large |
---|
626 | entities. |
---|
627 | </t> |
---|
628 | <t> |
---|
629 | If the server supports the Range header and the specified range or |
---|
630 | ranges are appropriate for the entity: |
---|
631 | <list style="symbols"> |
---|
632 | <t>The presence of a Range header in an unconditional GET modifies |
---|
633 | what is returned if the GET is otherwise successful. In other |
---|
634 | words, the response carries a status code of 206 (Partial |
---|
635 | Content) instead of 200 (OK).</t> |
---|
636 | |
---|
637 | <t>The presence of a Range header in a conditional GET (a request |
---|
638 | using one or both of If-Modified-Since and If-None-Match, or |
---|
639 | one or both of If-Unmodified-Since and If-Match) modifies what |
---|
640 | is returned if the GET is otherwise successful and the |
---|
641 | condition is true. It does not affect the 304 (Not Modified) |
---|
642 | response returned if the conditional is false.</t> |
---|
643 | </list> |
---|
644 | </t> |
---|
645 | <t> |
---|
646 | In some cases, it might be more appropriate to use the If-Range |
---|
647 | header (see <xref target="header.if-range"/>) in addition to the Range header. |
---|
648 | </t> |
---|
649 | <t> |
---|
650 | If a proxy that supports ranges receives a Range request, forwards |
---|
651 | the request to an inbound server, and receives an entire entity in |
---|
652 | reply, it SHOULD only return the requested range to its client. It |
---|
653 | SHOULD store the entire received response in its cache if that is |
---|
654 | consistent with its cache allocation policies. |
---|
655 | </t> |
---|
656 | </section> |
---|
657 | </section> |
---|
658 | </section> |
---|
659 | |
---|
660 | <section title="IANA Considerations" anchor="IANA.considerations"> |
---|
661 | <t> |
---|
662 | TBD. |
---|
663 | </t> |
---|
664 | </section> |
---|
665 | |
---|
666 | <section title="Security Considerations" anchor="security.considerations"> |
---|
667 | <t> |
---|
668 | No additional security considerations have been identified beyond |
---|
669 | those applicable to HTTP in general <xref target="Part1"/>. |
---|
670 | </t> |
---|
671 | </section> |
---|
672 | |
---|
673 | <section title="Acknowledgments" anchor="ack"> |
---|
674 | <t> |
---|
675 | Most of the specification of ranges is based on work originally done |
---|
676 | by Ari Luotonen and John Franks, with additional input from Steve |
---|
677 | Zilles. |
---|
678 | </t> |
---|
679 | <t> |
---|
680 | Based on an XML translation of RFC 2616 by Julian Reschke. |
---|
681 | </t> |
---|
682 | </section> |
---|
683 | </middle> |
---|
684 | <back> |
---|
685 | <references> |
---|
686 | |
---|
687 | <reference anchor="Part1"> |
---|
688 | <front> |
---|
689 | <title abbrev="HTTP/1.1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title> |
---|
690 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
691 | <organization abbrev="Day Software">Day Software</organization> |
---|
692 | <address><email>fielding@gbiv.com</email></address> |
---|
693 | </author> |
---|
694 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
695 | <organization>One Laptop per Child</organization> |
---|
696 | <address><email>jg@laptop.org</email></address> |
---|
697 | </author> |
---|
698 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
699 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
700 | <address><email>JeffMogul@acm.org</email></address> |
---|
701 | </author> |
---|
702 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
703 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
704 | <address><email>henrikn@microsoft.com</email></address> |
---|
705 | </author> |
---|
706 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
707 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
708 | <address><email>LMM@acm.org</email></address> |
---|
709 | </author> |
---|
710 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
711 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
712 | <address><email>paulle@microsoft.com</email></address> |
---|
713 | </author> |
---|
714 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
715 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
716 | <address><email>timbl@w3.org</email></address> |
---|
717 | </author> |
---|
718 | <date month="December" year="2007"/> |
---|
719 | </front> |
---|
720 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-00"/> |
---|
721 | |
---|
722 | </reference> |
---|
723 | |
---|
724 | <reference anchor="Part4"> |
---|
725 | <front> |
---|
726 | <title abbrev="HTTP/1.1">HTTP/1.1, part 4: Conditional Requests</title> |
---|
727 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
728 | <organization abbrev="Day Software">Day Software</organization> |
---|
729 | <address><email>fielding@gbiv.com</email></address> |
---|
730 | </author> |
---|
731 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
732 | <organization>One Laptop per Child</organization> |
---|
733 | <address><email>jg@laptop.org</email></address> |
---|
734 | </author> |
---|
735 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
736 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
737 | <address><email>JeffMogul@acm.org</email></address> |
---|
738 | </author> |
---|
739 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
740 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
741 | <address><email>henrikn@microsoft.com</email></address> |
---|
742 | </author> |
---|
743 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
744 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
745 | <address><email>LMM@acm.org</email></address> |
---|
746 | </author> |
---|
747 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
748 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
749 | <address><email>paulle@microsoft.com</email></address> |
---|
750 | </author> |
---|
751 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
752 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
753 | <address><email>timbl@w3.org</email></address> |
---|
754 | </author> |
---|
755 | <date month="December" year="2007"/> |
---|
756 | </front> |
---|
757 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p4-conditional-00"/> |
---|
758 | |
---|
759 | </reference> |
---|
760 | |
---|
761 | <reference anchor="RFC2616"> |
---|
762 | <front> |
---|
763 | <title>Hypertext Transfer Protocol -- HTTP/1.1</title> |
---|
764 | <author initials="R." surname="Fielding" fullname="R. Fielding"> |
---|
765 | <organization>University of California, Irvine</organization> |
---|
766 | <address><email>fielding@ics.uci.edu</email></address> |
---|
767 | </author> |
---|
768 | <author initials="J." surname="Gettys" fullname="J. Gettys"> |
---|
769 | <organization>W3C</organization> |
---|
770 | <address><email>jg@w3.org</email></address> |
---|
771 | </author> |
---|
772 | <author initials="J." surname="Mogul" fullname="J. Mogul"> |
---|
773 | <organization>Compaq Computer Corporation</organization> |
---|
774 | <address><email>mogul@wrl.dec.com</email></address> |
---|
775 | </author> |
---|
776 | <author initials="H." surname="Frystyk" fullname="H. Frystyk"> |
---|
777 | <organization>MIT Laboratory for Computer Science</organization> |
---|
778 | <address><email>frystyk@w3.org</email></address> |
---|
779 | </author> |
---|
780 | <author initials="L." surname="Masinter" fullname="L. Masinter"> |
---|
781 | <organization>Xerox Corporation</organization> |
---|
782 | <address><email>masinter@parc.xerox.com</email></address> |
---|
783 | </author> |
---|
784 | <author initials="P." surname="Leach" fullname="P. Leach"> |
---|
785 | <organization>Microsoft Corporation</organization> |
---|
786 | <address><email>paulle@microsoft.com</email></address> |
---|
787 | </author> |
---|
788 | <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee"> |
---|
789 | <organization>W3C</organization> |
---|
790 | <address><email>timbl@w3.org</email></address> |
---|
791 | </author> |
---|
792 | <date month="June" year="1999"/> |
---|
793 | </front> |
---|
794 | <seriesInfo name="RFC" value="2616"/> |
---|
795 | </reference> |
---|
796 | |
---|
797 | <reference anchor="RFC2046"> |
---|
798 | <front> |
---|
799 | <title abbrev="Media Types">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title> |
---|
800 | <author initials="N." surname="Freed" fullname="Ned Freed"> |
---|
801 | <organization>Innosoft International, Inc.</organization> |
---|
802 | <address> |
---|
803 | <postal> |
---|
804 | <street>1050 East Garvey Avenue South</street> |
---|
805 | <city>West Covina</city> |
---|
806 | <region>CA</region> |
---|
807 | <code>91790</code> |
---|
808 | <country>US</country></postal> |
---|
809 | <phone>+1 818 919 3600</phone> |
---|
810 | <facsimile>+1 818 919 3614</facsimile> |
---|
811 | <email>ned@innosoft.com</email></address></author> |
---|
812 | <author initials="N." surname="Borenstein" fullname="Nathaniel S. Borenstein"> |
---|
813 | <organization>First Virtual Holdings</organization> |
---|
814 | <address> |
---|
815 | <postal> |
---|
816 | <street>25 Washington Avenue</street> |
---|
817 | <city>Morristown</city> |
---|
818 | <region>NJ</region> |
---|
819 | <code>07960</code> |
---|
820 | <country>US</country></postal> |
---|
821 | <phone>+1 201 540 8967</phone> |
---|
822 | <facsimile>+1 201 993 3032</facsimile> |
---|
823 | <email>nsb@nsb.fv.com</email></address></author> |
---|
824 | <date month="November" year="1996"/> |
---|
825 | </front> |
---|
826 | <seriesInfo name="RFC" value="2046"/> |
---|
827 | </reference> |
---|
828 | |
---|
829 | </references> |
---|
830 | |
---|
831 | <section title="Internet Media Type multipart/byteranges" anchor="internet.media.type.multipart.byteranges"> |
---|
832 | <iref item="Media Type" subitem="multipart/byteranges" primary="true"/> |
---|
833 | <iref item="multipart/byteranges Media Type" primary="true"/> |
---|
834 | <t> |
---|
835 | When an HTTP 206 (Partial Content) response message includes the |
---|
836 | content of multiple ranges (a response to a request for multiple |
---|
837 | non-overlapping ranges), these are transmitted as a multipart |
---|
838 | message-body. The media type for this purpose is called |
---|
839 | "multipart/byteranges". |
---|
840 | </t><t> |
---|
841 | The multipart/byteranges media type includes two or more parts, each |
---|
842 | with its own Content-Type and Content-Range fields. The required |
---|
843 | boundary parameter specifies the boundary string used to separate |
---|
844 | each body-part. |
---|
845 | </t> |
---|
846 | <t> |
---|
847 | <list style="hanging"> |
---|
848 | <t hangText="Media Type name:"> |
---|
849 | multipart |
---|
850 | </t> |
---|
851 | <t hangText="Media subtype name:"> |
---|
852 | byteranges |
---|
853 | </t> |
---|
854 | <t hangText="Required parameters:"> |
---|
855 | boundary |
---|
856 | </t> |
---|
857 | <t hangText="Optional parameters:"> |
---|
858 | none |
---|
859 | </t> |
---|
860 | <t hangText="Encoding considerations:"> |
---|
861 | only "7bit", "8bit", or "binary" are permitted |
---|
862 | </t> |
---|
863 | <t hangText="Security considerations:"> |
---|
864 | none |
---|
865 | </t> |
---|
866 | </list> |
---|
867 | </t> |
---|
868 | <figure><preamble> |
---|
869 | For example: |
---|
870 | </preamble><artwork type="example"><![CDATA[ |
---|
871 | HTTP/1.1 206 Partial Content |
---|
872 | Date: Wed, 15 Nov 1995 06:25:24 GMT |
---|
873 | Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT |
---|
874 | Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES |
---|
875 | |
---|
876 | --THIS_STRING_SEPARATES |
---|
877 | Content-type: application/pdf |
---|
878 | Content-range: bytes 500-999/8000 |
---|
879 | |
---|
880 | ...the first range... |
---|
881 | --THIS_STRING_SEPARATES |
---|
882 | Content-type: application/pdf |
---|
883 | Content-range: bytes 7000-7999/8000 |
---|
884 | |
---|
885 | ...the second range |
---|
886 | --THIS_STRING_SEPARATES-- |
---|
887 | ]]></artwork></figure> |
---|
888 | <t> |
---|
889 | Notes: |
---|
890 | <list style="numbers"> |
---|
891 | <t>Additional CRLFs may precede the first boundary string in the |
---|
892 | entity.</t> |
---|
893 | |
---|
894 | <t>Although RFC 2046 <xref target="RFC2046"/> permits the boundary string to be |
---|
895 | quoted, some existing implementations handle a quoted boundary |
---|
896 | string incorrectly.</t> |
---|
897 | |
---|
898 | <t>A number of browsers and servers were coded to an early draft |
---|
899 | of the byteranges specification to use a media type of |
---|
900 | multipart/x-byteranges<iref item="multipart/x-byteranges Media Type"/><iref item="Media Type" subitem="multipart/x-byteranges"/>, which is almost, but not quite |
---|
901 | compatible with the version documented in HTTP/1.1.</t> |
---|
902 | </list> |
---|
903 | </t> |
---|
904 | </section> |
---|
905 | |
---|
906 | <section title="Changes from RFC 2068" anchor="changes.from.rfc.2068"> |
---|
907 | <t> |
---|
908 | There are situations where a server (especially a proxy) does not |
---|
909 | know the full length of a response but is capable of serving a |
---|
910 | byterange request. We therefore need a mechanism to allow byteranges |
---|
911 | with a content-range not indicating the full length of the message. |
---|
912 | (<xref target="header.content-range"/>) |
---|
913 | </t> |
---|
914 | <t> |
---|
915 | Range request responses would become very verbose if all meta-data |
---|
916 | were always returned; by allowing the server to only send needed |
---|
917 | headers in a 206 response, this problem can be avoided. |
---|
918 | </t> |
---|
919 | <t> |
---|
920 | Fix problem with unsatisfiable range requests; there are two cases: |
---|
921 | syntactic problems, and range doesn't exist in the document. The 416 |
---|
922 | status code was needed to resolve this ambiguity needed to indicate |
---|
923 | an error for a byte range request that falls outside of the actual |
---|
924 | contents of a document. (Section <xref target="status.416" format="counter"/>, <xref target="header.content-range" format="counter"/>) |
---|
925 | </t> |
---|
926 | </section> |
---|
927 | |
---|
928 | </back> |
---|
929 | </rfc> |
---|