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

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

Work-in-progress: hyperlink header field definitions(P5)

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