Changeset 1623 for draft-ietf-httpbis/latest/p5-range.html
- Timestamp:
- 26/03/12 16:27:31 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p5-range.html
r1600 r1623 460 460 } 461 461 @bottom-center { 462 content: "Expires September 18, 2012";462 content: "Expires September 27, 2012"; 463 463 } 464 464 @bottom-right { … … 503 503 <meta name="dct.creator" content="Reschke, J. F."> 504 504 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 505 <meta name="dct.issued" scheme="ISO8601" content="2012-03- 17">505 <meta name="dct.issued" scheme="ISO8601" content="2012-03-26"> 506 506 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 507 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range -specificrequests and the rules for constructing and combining responses to those requests.">508 <meta name="description" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range -specificrequests and the rules for constructing and combining responses to those requests.">507 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range requests and the rules for constructing and combining responses to those requests."> 508 <meta name="description" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range requests and the rules for constructing and combining responses to those requests."> 509 509 </head> 510 510 <body onload="init();"> … … 529 529 </tr> 530 530 <tr> 531 <td class="left">Expires: September 18, 2012</td>531 <td class="left">Expires: September 27, 2012</td> 532 532 <td class="right">J. Reschke, Editor</td> 533 533 </tr> … … 538 538 <tr> 539 539 <td class="left"></td> 540 <td class="right">March 17, 2012</td>540 <td class="right">March 26, 2012</td> 541 541 </tr> 542 542 </tbody> … … 548 548 seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. 549 549 </p> 550 <p>Part 5 defines range -specificrequests and the rules for constructing and combining responses to those requests.</p>550 <p>Part 5 defines range requests and the rules for constructing and combining responses to those requests.</p> 551 551 <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1> 552 552 <p>Discussion of this draft should take place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived … … 566 566 in progress”. 567 567 </p> 568 <p>This Internet-Draft will expire on September 18, 2012.</p>568 <p>This Internet-Draft will expire on September 27, 2012.</p> 569 569 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 570 570 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 711 711 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>> 712 712 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 713 <a href="#core.rules" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 8</a>>713 <a href="#core.rules" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 6.1</a>> 714 714 </pre><h3 id="rfc.section.1.2.2"><a href="#rfc.section.1.2.2">1.2.2</a> <a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3> 715 715 <p id="rfc.section.1.2.2.p.1">The ABNF rules below are defined in other parts:</p> … … 757 757 </li> 758 758 </ul> 759 <p id="rfc.section.3.1.p.3">If the 206 response is the result of an If-Range request, the response<em class="bcp14">SHOULD NOT</em> include other representation header fields. Otherwise, the response <em class="bcp14">MUST</em> include all of the representation header fields that would have been returned with a 200 (OK) response to the same request.759 <p id="rfc.section.3.1.p.3">If a 206 is sent in response to a request with an If-Range header field, it <em class="bcp14">SHOULD NOT</em> include other representation header fields. Otherwise, the response <em class="bcp14">MUST</em> include all of the representation header fields that would have been returned with a 200 (OK) response to the same request. 760 760 </p> 761 761 <p id="rfc.section.3.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 206 responses. … … 797 797 as defined in <a href="#internet.media.type.multipart.byteranges" title="Internet Media Type multipart/byteranges">Appendix A</a>. 798 798 </p> 799 <p id="rfc.section.4.1.p.4">A server <em class="bcp14">MAY</em> combine requested ranges when those ranges are overlapping (see <a href="# security.considerations" title="Security Considerations">Section 7</a>).799 <p id="rfc.section.4.1.p.4">A server <em class="bcp14">MAY</em> combine requested ranges when those ranges are overlapping (see <a href="#overlapping.ranges" title="Overlapping Ranges">Section 7.1</a>). 800 800 </p> 801 801 <p id="rfc.section.4.1.p.5">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. 802 802 </p> 803 <p id="rfc.section.4.1.p.6">When a client requestsmultiple ranges in one request, the server <em class="bcp14">SHOULD</em> return them in the order that they appeared in the request.803 <p id="rfc.section.4.1.p.6">When a client asks for multiple ranges in one request, the server <em class="bcp14">SHOULD</em> return them in the order that they appeared in the request. 804 804 </p> 805 805 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="combining.byte.ranges" href="#combining.byte.ranges">Combining Ranges</a></h2> … … 1585 1585 </li> 1586 1586 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1.2.1</a>, <a href="#rfc.xref.Part2.2">1.2.1</a>, <a href="#Part2"><b>9.1</b></a><ul> 1587 <li><em>Section 8</em> <a href="#rfc.xref.Part2.2">1.2.1</a></li>1587 <li><em>Section 6.1</em> <a href="#rfc.xref.Part2.2">1.2.1</a></li> 1588 1588 </ul> 1589 1589 </li>
Note: See TracChangeset
for help on using the changeset viewer.