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

Last change on this file since 1690 was 1689, checked in by julian.reschke@…, 7 years ago

tune contact information for Julian Reschke

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