Changeset 1623


Ignore:
Timestamp:
Mar 26, 2012, 9:27:31 AM (8 years ago)
Author:
ylafon@…
Message:

editorial changes (typos identified in <http://lists.w3.org/Archives/Public/ietf-http-wg/2012JanMar/0891.html>)

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p5-range.html

    r1600 r1623  
    460460  }
    461461  @bottom-center {
    462        content: "Expires September 18, 2012";
     462       content: "Expires September 27, 2012";
    463463  }
    464464  @bottom-right {
     
    503503      <meta name="dct.creator" content="Reschke, J. F.">
    504504      <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">
    506506      <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 &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range-specific 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 &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests 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 &#34;HTTP/1.1&#34; 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 &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range requests and the rules for constructing and combining responses to those requests.">
    509509   </head>
    510510   <body onload="init();">
     
    529529            </tr>
    530530            <tr>
    531                <td class="left">Expires: September 18, 2012</td>
     531               <td class="left">Expires: September 27, 2012</td>
    532532               <td class="right">J. Reschke, Editor</td>
    533533            </tr>
     
    538538            <tr>
    539539               <td class="left"></td>
    540                <td class="right">March 17, 2012</td>
     540               <td class="right">March 26, 2012</td>
    541541            </tr>
    542542         </tbody>
     
    548548         seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616.
    549549      </p> 
    550       <p>Part 5 defines range-specific requests 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>
    551551      <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1>
    552552      <p>Discussion of this draft should take place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived
     
    566566         in progress”.
    567567      </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>
    569569      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    570570      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    711711      <div id="rfc.figure.u.1"></div><pre class="inline">  <a href="#core.rules" class="smpl">OWS</a>        = &lt;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>&gt;
    712712  <a href="#core.rules" class="smpl">token</a>      = &lt;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>&gt;
    713   <a href="#core.rules" class="smpl">HTTP-date</a>  = &lt;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>&gt;
     713  <a href="#core.rules" class="smpl">HTTP-date</a>  = &lt;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>&gt;
    714714</pre><h3 id="rfc.section.1.2.2"><a href="#rfc.section.1.2.2">1.2.2</a>&nbsp;<a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3>
    715715      <p id="rfc.section.1.2.2.p.1">The ABNF rules below are defined in other parts:</p>
     
    757757         </li>
    758758      </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.
    760760      </p>
    761761      <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.
     
    797797         as defined in <a href="#internet.media.type.multipart.byteranges" title="Internet Media Type multipart/byteranges">Appendix&nbsp;A</a>.
    798798      </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&nbsp;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&nbsp;7.1</a>).
    800800      </p>
    801801      <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.
    802802      </p>
    803       <p id="rfc.section.4.1.p.6">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.
     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.
    804804      </p>
    805805      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="combining.byte.ranges" href="#combining.byte.ranges">Combining Ranges</a></h2>
     
    15851585                  </li>
    15861586                  <li><em>Part2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">1.2.1</a></li>
     1587                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">1.2.1</a></li>
    15881588                     </ul>
    15891589                  </li>
  • draft-ietf-httpbis/latest/p5-range.xml

    r1600 r1623  
    108108</t>
    109109<t>
    110    Part 5 defines range-specific requests and the rules for constructing and
     110   Part 5 defines range requests and the rules for constructing and
    111111   combining responses to those requests.
    112112</t>
     
    340340</t>
    341341<t>
    342    If the 206 response is the result of an If-Range request, the response
     342   If a 206 is sent in response to a request with an If-Range header field, it
    343343   &SHOULD-NOT; include other representation header fields. Otherwise, the response
    344344   &MUST; include all of the representation header fields that would have been returned
     
    412412<t>
    413413   A server &MAY; combine requested ranges when those ranges are overlapping
    414    (see <xref target="security.considerations"/>).
     414   (see <xref target="overlapping.ranges"/>).
    415415</t>
    416416<t>
     
    423423</t>
    424424<t>
    425    When a client requests multiple ranges in one request, the
     425   When a client asks for multiple ranges in one request, the
    426426   server &SHOULD; return them in the order that they appeared in the
    427427   request.
Note: See TracChangeset for help on using the changeset viewer.