Changeset 1460 for draft-ietf-httpbis
- Timestamp:
- 27/10/11 20:13:52 (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p5-range.html
r1457 r1460 790 790 selected resource. A response with status code 206 (Partial Content) <em class="bcp14">MUST NOT</em> include a Content-Range field with a byte-range-resp-spec of "*". 791 791 </p> 792 <p id="rfc.section.5.2.p.8">Examples of byte-content-range-spec values, assuming that the representation contains a total of 1234 bytes: </p> 792 <p id="rfc.section.5.2.p.8">The "Content-Range" header field has no meaning for status codes that does not explicitly describe its semantic. Currently, 793 only status codes 206 (Partial Content) and 416 (Requested range not satisfiable) describe the meaning of this header field. 794 </p> 795 <p id="rfc.section.5.2.p.9">Examples of byte-content-range-spec values, assuming that the representation contains a total of 1234 bytes: </p> 793 796 <ul> 794 797 <li>The first 500 bytes: … … 805 808 </pre> </li> 806 809 </ul> 807 <p id="rfc.section.5.2.p. 9">When an HTTP message includes the content of a single range (for example, a response to a request for a single range, or to810 <p id="rfc.section.5.2.p.10">When an HTTP message includes the content of a single range (for example, a response to a request for a single range, or to 808 811 a request for a set of ranges that overlap without any holes), this content is transmitted with a Content-Range header field, 809 812 and a Content-Length header field showing the number of bytes actually transferred. For example, … … 815 818 Content-Length: 26012 816 819 Content-Type: image/gif 817 </pre><p id="rfc.section.5.2.p.1 1">When an HTTP message includes the content of multiple ranges (for example, a response to a request for multiple non-overlapping820 </pre><p id="rfc.section.5.2.p.12">When an HTTP message includes the content of multiple ranges (for example, a response to a request for multiple non-overlapping 818 821 ranges), these are transmitted as a multipart message. The multipart media type used for this purpose is "multipart/byteranges" 819 822 as defined in <a href="#internet.media.type.multipart.byteranges" title="Internet Media Type multipart/byteranges">Appendix A</a>. 820 823 </p> 821 <p id="rfc.section.5.2.p.1 2">A response to a request for a single range <em class="bcp14">MUST NOT</em> be sent using the multipart/byteranges media type. A response to a request for multiple ranges, whose result is a single range, <em class="bcp14">MAY</em> be sent as a multipart/byteranges media type with one part. A client that cannot decode a multipart/byteranges message <em class="bcp14">MUST NOT</em> ask for multiple ranges in a single request.822 </p> 823 <p id="rfc.section.5.2.p.1 3">When a client requests multiple ranges in one request, the server <em class="bcp14">SHOULD</em> return them in the order that they appeared in the request.824 </p> 825 <p id="rfc.section.5.2.p.1 4">If the server ignores a byte-range-spec because it is syntactically invalid, the server <em class="bcp14">SHOULD</em> treat the request as if the invalid Range header field did not exist. (Normally, this means return a 200 response containing824 <p id="rfc.section.5.2.p.13">A response to a request for a single range <em class="bcp14">MUST NOT</em> be sent using the multipart/byteranges media type. A response to a request for multiple ranges, whose result is a single range, <em class="bcp14">MAY</em> be sent as a multipart/byteranges media type with one part. A client that cannot decode a multipart/byteranges message <em class="bcp14">MUST NOT</em> ask for multiple ranges in a single request. 825 </p> 826 <p id="rfc.section.5.2.p.14">When a client requests multiple ranges in one request, the server <em class="bcp14">SHOULD</em> return them in the order that they appeared in the request. 827 </p> 828 <p id="rfc.section.5.2.p.15">If the server ignores a byte-range-spec because it is syntactically invalid, the server <em class="bcp14">SHOULD</em> treat the request as if the invalid Range header field did not exist. (Normally, this means return a 200 response containing 826 829 the full representation). 827 830 </p> 828 <p id="rfc.section.5.2.p.1 5">If the server receives a request (other than one including an If-Range header field) with an unsatisfiable Range header field831 <p id="rfc.section.5.2.p.16">If the server receives a request (other than one including an If-Range header field) with an unsatisfiable Range header field 829 832 (that is, all of whose byte-range-spec values have a first-byte-pos value greater than the current length of the selected 830 833 resource), it <em class="bcp14">SHOULD</em> return a response code of 416 (Requested range not satisfiable) (<a href="#status.416" id="rfc.xref.status.416.1" title="416 Requested Range Not Satisfiable">Section 3.2</a>). 831 834 </p> 832 <div class="note" id="rfc.section.5.2.p.1 6">835 <div class="note" id="rfc.section.5.2.p.17"> 833 836 <p> <b>Note:</b> Clients cannot depend on servers to send a 416 (Requested range not satisfiable) response instead of a 200 (OK) response for 834 837 an unsatisfiable Range header field, since not all servers implement this header field. … … 1425 1428 </li> 1426 1429 <li> <<a href="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/319">http://trac.tools.ietf.org/wg/httpbis/trac/ticket/319</a>>: "case sensitivity of ranges in p5" 1430 </li> 1431 <li> <<a href="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/301">http://trac.tools.ietf.org/wg/httpbis/trac/ticket/301</a>>: "Content-Range on responses other than 206" 1427 1432 </li> 1428 1433 </ul>
Note: See TracChangeset
for help on using the changeset viewer.