![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 931 for draft-ietf-httpbis/latest
- Timestamp:
- 24/07/10 14:41:11 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
-
p5-range.html (modified) (8 diffs)
-
p6-cache.html (modified) (1 diff)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p5-range.html
r928 r931 536 536 </ul> 537 537 </li> 538 <li class="tocline0">2. <a href="#range.units">Range Units</a></li> 538 <li class="tocline0">2. <a href="#range.units">Range Units</a><ul class="toc"> 539 <li class="tocline1">2.1 <a href="#range.specifier.registry">Range Specifier Registry</a></li> 540 </ul> 541 </li> 539 542 <li class="tocline0">3. <a href="#status.code.definitions">Status Code Definitions</a><ul class="toc"> 540 543 <li class="tocline1">3.1 <a href="#status.206">206 Partial Content</a></li> … … 557 560 <li class="tocline1">6.1 <a href="#status.code.registration">Status Code Registration</a></li> 558 561 <li class="tocline1">6.2 <a href="#header.field.registration">Header Field Registration</a></li> 562 <li class="tocline1">6.3 <a href="#range.specifier.registration">Range Specifier Registration</a></li> 559 563 </ul> 560 564 </li> … … 638 642 <a href="#range.units" class="smpl">other-range-unit</a> = <a href="#core.rules" class="smpl">token</a> 639 643 </pre><p id="rfc.section.2.p.3">HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges. The only range 640 unit defined by HTTP/1.1 is "bytes". 644 unit defined by HTTP/1.1 is "bytes". Additional specifiers can be defined as described in <a href="#range.specifier.registry" title="Range Specifier Registry">Section 2.1</a>. 641 645 </p> 642 646 <p id="rfc.section.2.p.4">If a range unit is not understood in a request, a server <em class="bcp14">MUST</em> ignore the whole Range header (<a href="#header.range" id="rfc.xref.header.range.2" title="Range">Section 5.4</a>). If a range unit is not understood in a response, an intermediary <em class="bcp14">SHOULD</em> pass the response to the client; a client <em class="bcp14">MUST</em> fail. 647 </p> 648 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="range.specifier.registry" href="#range.specifier.registry">Range Specifier Registry</a></h2> 649 <p id="rfc.section.2.1.p.1">The HTTP Ranger Specifier Registry defines the name space for the range specifier names.</p> 650 <p id="rfc.section.2.1.p.2">Registrations <em class="bcp14">MUST</em> include the following fields: 651 </p> 652 <ul> 653 <li>Name</li> 654 <li>Description</li> 655 <li>Pointer to specification text</li> 656 </ul> 657 <p id="rfc.section.2.1.p.3">Values to be added to this name space are subject to IETF review (<a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>). 658 </p> 659 <p id="rfc.section.2.1.p.4">The registry itself is maintained at <<a href="http://www.iana.org/assignments/http-range-specifiers">http://www.iana.org/assignments/http-range-specifiers</a>>. 643 660 </p> 644 661 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="status.code.definitions" href="#status.code.definitions">Status Code Definitions</a></h1> … … 975 992 </div> 976 993 <p id="rfc.section.6.2.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 994 <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a id="range.specifier.registration" href="#range.specifier.registration">Range Specifier Registration</a></h2> 995 <p id="rfc.section.6.3.p.1">The registration procedure for HTTP Range Specifiers is defined by <a href="#range.specifier.registry" title="Range Specifier Registry">Section 2.1</a> of this document. 996 </p> 997 <p id="rfc.section.6.3.p.2">The HTTP Range Specifier Registry should be created at <<a href="http://www.iana.org/assignments/http-range-specifiers">http://www.iana.org/assignments/http-range-specifiers</a>> and be populated with the registrations below: 998 </p> 999 <div id="rfc.table.3"> 1000 <div id="iana.range.specifiers.table"></div> 1001 <table class="tt full left" cellpadding="3" cellspacing="0"> 1002 <thead> 1003 <tr> 1004 <th>Range Specifier Name</th> 1005 <th>Description</th> 1006 <th>Reference</th> 1007 </tr> 1008 </thead> 1009 <tbody> 1010 <tr> 1011 <td class="left">bytes</td> 1012 <td class="left">a range of octets</td> 1013 <td class="left">(this specification)</td> 1014 </tr> 1015 </tbody> 1016 </table> 1017 </div> 1018 <p id="rfc.section.6.3.p.3">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 977 1019 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 978 1020 <p id="rfc.section.7.p.1">No additional security considerations have been identified beyond those applicable to HTTP in general <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. … … 1016 1058 <h2 id="rfc.references.2"><a href="#rfc.section.9.2" id="rfc.section.9.2">9.2</a> Informative References 1017 1059 </h2> 1018 <table> 1060 <table> 1019 1061 <tr> 1020 1062 <td class="reference"><b id="RFC2616">[RFC2616]</b></td> … … 1030 1072 <td class="reference"><b id="RFC4288">[RFC4288]</b></td> 1031 1073 <td class="top"><a href="mailto:ned.freed@mrochek.com" title="Sun Microsystems">Freed, N.</a> and <a href="mailto:klensin+ietf@jck.com">J. Klensin</a>, “<a href="http://tools.ietf.org/html/rfc4288">Media Type Specifications and Registration Procedures</a>”, BCP 13, RFC 4288, December 2005. 1074 </td> 1075 </tr> 1076 <tr> 1077 <td class="reference"><b id="RFC5226">[RFC5226]</b></td> 1078 <td class="top"><a href="mailto:narten@us.ibm.com" title="IBM">Narten, T.</a> and <a href="mailto:Harald@Alvestrand.no" title="Google">H. Alvestrand</a>, “<a href="http://tools.ietf.org/html/rfc5226">Guidelines for Writing an IANA Considerations Section in RFCs</a>”, BCP 26, RFC 5226, May 2008. 1032 1079 </td> 1033 1080 </tr> … … 1307 1354 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/220">http://tools.ietf.org/wg/httpbis/trac/ticket/220</a>>: "consider removing the 'changes from 2068' sections" 1308 1355 </li> 1356 </ul> 1357 <p id="rfc.section.D.12.p.2">Ongoing work on Custom Ranges (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/85">http://tools.ietf.org/wg/httpbis/trac/ticket/85</a>>): 1358 </p> 1359 <ul> 1360 <li>Add IANA registry.</li> 1309 1361 </ul> 1310 1362 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> … … 1409 1461 <li class="indline1"><em>RFC3864</em> <a class="iref" href="#rfc.xref.RFC3864.1">6.2</a>, <a class="iref" href="#RFC3864"><b>9.2</b></a></li> 1410 1462 <li class="indline1"><em>RFC4288</em> <a class="iref" href="#RFC4288"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC4288.1">A</a></li> 1463 <li class="indline1"><em>RFC5226</em> <a class="iref" href="#rfc.xref.RFC5226.1">2.1</a>, <a class="iref" href="#RFC5226"><b>9.2</b></a><ul class="ind"> 1464 <li class="indline1"><em>Section 4.1</em> <a class="iref" href="#rfc.xref.RFC5226.1">2.1</a></li> 1465 </ul> 1466 </li> 1411 1467 <li class="indline1"><em>RFC5234</em> <a class="iref" href="#rfc.xref.RFC5234.1">1.2</a>, <a class="iref" href="#rfc.xref.RFC5234.2">1.2</a>, <a class="iref" href="#RFC5234"><b>9.1</b></a><ul class="ind"> 1412 1468 <li class="indline1"><em>Appendix B.1</em> <a class="iref" href="#rfc.xref.RFC5234.2">1.2</a></li> -
draft-ietf-httpbis/latest/p6-cache.html
r928 r931 932 932 </p> 933 933 <p id="rfc.section.2.4.p.5">A full response (i.e., one with a response body) indicates that none of the stored responses nominated in the conditional 934 request is suitable. Instead, the full response is used both to satisfy the request and replace the stored response. <span class="comment" id="TODO-req-missing">[<a href="#TODO-req-missing" class="smpl">TODO-req-missing</a>: Should there be a requirement here?]</span>934 request is suitable. Instead, the full response <em class="bcp14">SHOULD</em> be used to satisfy the request and <em class="bcp14">MAY</em> replace the stored response. 935 935 </p> 936 936 <p id="rfc.section.2.4.p.6">If a cache receives a 5xx response while attempting to validate a response, it <em class="bcp14">MAY</em> either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it <em class="bcp14">MAY</em> return a previously stored response (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section 2.3.3</a>).
Note: See TracChangeset
for help on using the changeset viewer.
