source: draft-ietf-httpbis/18/p5-range.xml @ 1499

Last change on this file since 1499 was 1499, checked in by julian.reschke@…, 8 years ago

prepare for publication of -18 on Jan 04.

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