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

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

Update to latest version of rfc2629.xslt, add next/prev link relations (does not affect TXT version)

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