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

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

Rephrase description of conformance; explain how the spec handles error handling (see #186)

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