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

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

refresh inclusions, regen HTML

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