Changeset 1732


Ignore:
Timestamp:
Jul 5, 2012, 11:32:41 PM (7 years ago)
Author:
julian.reschke@…
Message:

Work-in-progress: hyperlink status codes definitions (P5)

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.html

    r1728 r1732  
    449449  }
    450450  @bottom-center {
    451        content: "Expires January 6, 2013";
     451       content: "Expires January 7, 2013";
    452452  }
    453453  @bottom-right {
     
    497497      <meta name="dct.creator" content="Reschke, J. F.">
    498498      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    499       <meta name="dct.issued" scheme="ISO8601" content="2012-07-05">
     499      <meta name="dct.issued" scheme="ISO8601" content="2012-07-06">
    500500      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    501501      <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 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields. Furthermore, it defines HTTP message content, metadata, and content negotiation.">
     
    528528            </tr>
    529529            <tr>
    530                <td class="left">Expires: January 6, 2013</td>
     530               <td class="left">Expires: January 7, 2013</td>
    531531               <td class="right">greenbytes</td>
    532532            </tr>
    533533            <tr>
    534534               <td class="left"></td>
    535                <td class="right">July 5, 2012</td>
     535               <td class="right">July 6, 2012</td>
    536536            </tr>
    537537         </tbody>
     
    563563         in progress”.
    564564      </p>
    565       <p>This Internet-Draft will expire on January 6, 2013.</p>
     565      <p>This Internet-Draft will expire on January 7, 2013.</p>
    566566      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    567567      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    23302330      <p id="rfc.section.6.p.2">A "<dfn>payload</dfn>" in HTTP is always a partial or complete representation of some resource. We use separate terms for payload and representation
    23312331         because some messages contain only the associated representation's header fields (e.g., responses to HEAD) or only some part(s)
    2332          of the representation (e.g., the 206 status code).
     2332         of the representation (e.g., the <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> status code).
    23332333      </p>
    23342334      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="payload.header.fields" href="#payload.header.fields">Payload Header Fields</a></h2>
     
    23912391            target resource.
    23922392         </li>
    2393          <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response payload is a partial
    2394             representation of the target resource.
     2393         <li>If the response status code is 204, <a href="p5-range.html#status.206" class="smpl">206</a>, or 304 and the request method was GET or HEAD, the response payload is a partial representation of the target resource.
    23952394         </li>
    23962395         <li>If the response has a Content-Location header field, and that URI is the same as the effective request URI, the response payload
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1728 r1732  
    26202620   and representation because some messages contain only the associated
    26212621   representation's header fields (e.g., responses to HEAD) or only some
    2622    part(s) of the representation (e.g., the 206 status code).
     2622   part(s) of the representation (e.g., the <x:ref>206 (Partial Content)</x:ref>
     2623   status code).
    26232624</t>
    26242625<section title="Payload Header Fields" anchor="payload.header.fields">
     
    27052706   <t>If the response status code is 200 or 203 and the request method was GET,
    27062707   the response payload is a representation of the target resource.</t>
    2707    <t>If the response status code is 204, 206, or 304 and the request method was GET
     2708   <t>If the response status code is 204, <x:ref>206</x:ref>, or 304 and the request method was GET
    27082709   or HEAD, the response payload is a partial representation of the target
    27092710   resource.</t>
     
    46624663  </front>
    46634664  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-&ID-VERSION;"/>
    4664   <x:source href="p5-range.xml" basename="p5-range"/>
     4665  <x:source href="p5-range.xml" basename="p5-range">
     4666    <x:defines>206</x:defines>
     4667    <x:defines>206 (Partial Content)</x:defines>
     4668  </x:source>
    46654669</reference>
    46664670
  • draft-ietf-httpbis/latest/p5-range.html

    r1725 r1732  
    449449  }
    450450  @bottom-center {
    451        content: "Expires January 6, 2013";
     451       content: "Expires January 7, 2013";
    452452  }
    453453  @bottom-right {
     
    492492      <meta name="dct.creator" content="Reschke, J. F.">
    493493      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    494       <meta name="dct.issued" scheme="ISO8601" content="2012-07-05">
     494      <meta name="dct.issued" scheme="ISO8601" content="2012-07-06">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    496496      <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.">
     
    518518            </tr>
    519519            <tr>
    520                <td class="left">Expires: January 6, 2013</td>
     520               <td class="left">Expires: January 7, 2013</td>
    521521               <td class="right">J. Reschke, Editor</td>
    522522            </tr>
     
    527527            <tr>
    528528               <td class="left"></td>
    529                <td class="right">July 5, 2012</td>
     529               <td class="right">July 6, 2012</td>
    530530            </tr>
    531531         </tbody>
     
    555555         in progress”.
    556556      </p>
    557       <p>This Internet-Draft will expire on January 6, 2013.</p>
     557      <p>This Internet-Draft will expire on January 7, 2013.</p>
    558558      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    559559      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    805805      </p>
    806806      <p id="rfc.section.4.2.p.4">If the new response is a <a href="#status.206" class="smpl">206 (Partial Content)</a> response and at least one of the matching stored responses is a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, then the combined response header fields consist of the most recent 200 response's header fields. If all of the matching
    807          stored responses are 206 responses, then the stored response with the most header fields is used as the source of header fields
    808          for the combined response, except that the client <em class="bcp14">MUST</em> use other header fields provided in the new response, aside from Content-Range, to replace all instances of the corresponding
     807         stored responses are <a href="#status.206" class="smpl">206</a> responses, then the stored response with the most header fields is used as the source of header fields for the combined response,
     808         except that the client <em class="bcp14">MUST</em> use other header fields provided in the new response, aside from Content-Range, to replace all instances of the corresponding
    809809         header fields in the stored response.
    810810      </p>
    811811      <p id="rfc.section.4.2.p.5">The combined response message body consists of the union of partial content ranges in the new response and each of the selected
    812812         responses. If the union consists of the entire range of the representation, then the combined response <em class="bcp14">MUST</em> be recorded as a complete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response with a Content-Length header field that reflects the complete length. Otherwise, the combined response(s) <em class="bcp14">MUST</em> include a Content-Range header field describing the included range(s) and be recorded as incomplete. If the union consists
    813          of a discontinuous range of the representation, then the client <em class="bcp14">MAY</em> store it as either a multipart range response or as multiple 206 responses with one continuous range each.
     813         of a discontinuous range of the representation, then the client <em class="bcp14">MAY</em> store it as either a multipart range response or as multiple <a href="#status.206" class="smpl">206</a> responses with one continuous range each.
    814814      </p>
    815815      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>
     
    12831283      </ol>
    12841284      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1>
    1285       <p id="rfc.section.B.p.1">Clarify that it is not ok to use a weak validator in a 206 response. (<a href="#status.206" id="rfc.xref.status.206.2" title="206 Partial Content">Section&nbsp;3.1</a>)
     1285      <p id="rfc.section.B.p.1">Clarify that it is not ok to use a weak validator in a <a href="#status.206" class="smpl">206</a> response. (<a href="#status.206" id="rfc.xref.status.206.2" title="206 Partial Content">Section&nbsp;3.1</a>)
    12861286      </p>
    12871287      <p id="rfc.section.B.p.2">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section&nbsp;5</a>)
  • draft-ietf-httpbis/latest/p5-range.xml

    r1726 r1732  
    312312  <iref primary="true" item="206 Partial Content (status code)" x:for-anchor=""/>
    313313  <iref primary="true" item="Status Codes" subitem="206 Partial Content" x:for-anchor=""/>
     314  <x:anchor-alias value="206"/>
    314315  <x:anchor-alias value="206 (Partial Content)"/>
    315316<t>
     
    461462   of the matching stored responses is a <x:ref>200 (OK)</x:ref>, then the combined response
    462463   header fields consist of the most recent 200 response's header fields.
    463    If all of the matching stored responses are 206 responses, then the
     464   If all of the matching stored responses are <x:ref>206</x:ref> responses, then the
    464465   stored response with the most header fields is used as the source of
    465466   header fields for the combined response, except that the client &MUST;
     
    478479   incomplete.  If the union consists of a discontinuous range of the
    479480   representation, then the client &MAY; store it as either a multipart range
    480    response or as multiple 206 responses with one continuous range each.
     481   response or as multiple <x:ref>206</x:ref> responses with one continuous range each.
    481482</t>
    482483</section>
     
    13521353<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
    13531354<t>
    1354   Clarify that it is not ok to use a weak validator in a 206 response.
     1355  Clarify that it is not ok to use a weak validator in a <x:ref>206</x:ref> response.
    13551356  (<xref target="status.206"/>)
    13561357</t>
  • draft-ietf-httpbis/latest/p6-cache.html

    r1731 r1732  
    965965      <h4 id="rfc.section.2.3.1.1"><a href="#rfc.section.2.3.1.1">2.3.1.1</a>&nbsp;<a id="heuristic.freshness" href="#heuristic.freshness">Calculating Heuristic Freshness</a></h4>
    966966      <p id="rfc.section.2.3.1.1.p.1">If no explicit expiration time is present in a stored response that has a status code whose definition allows heuristic freshness
    967          to be used (including the following in <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>: 200, 203, 206, 300, 301 and 410), a cache <em class="bcp14">MAY</em> calculate a heuristic expiration time. A cache <em class="bcp14">MUST NOT</em> use heuristics to determine freshness for responses with status codes that do not explicitly allow it.
     967         to be used (including the following in <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>: 200, 203, <a href="p5-range.html#status.206" class="smpl">206</a>, 300, 301 and 410), a cache <em class="bcp14">MAY</em> calculate a heuristic expiration time. A cache <em class="bcp14">MUST NOT</em> use heuristics to determine freshness for responses with status codes that do not explicitly allow it.
    968968      </p>
    969969      <p id="rfc.section.2.3.1.1.p.2">When a heuristic is used to calculate freshness lifetime, a cache <em class="bcp14">SHOULD</em> attach a Warning header field with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning
  • draft-ietf-httpbis/latest/p6-cache.xml

    r1731 r1732  
    683683   If no explicit expiration time is present in a stored response that has a
    684684   status code whose definition allows heuristic freshness to be used
    685    (including the following in &status-codes;: 200, 203, 206, 300, 301 and
     685   (including the following in &status-codes;: 200, 203, <x:ref>206</x:ref>, 300, 301 and
    686686   410), a cache &MAY; calculate a heuristic expiration time. A cache &MUST-NOT;
    687687   use heuristics to determine freshness for responses with status codes that do
     
    23442344    <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-&ID-VERSION;" />
    23452345    <x:source basename="p5-range" href="p5-range.xml">
     2346      <x:defines>206</x:defines>
    23462347      <x:defines>206 (Partial Content)</x:defines>
    23472348    </x:source>
Note: See TracChangeset for help on using the changeset viewer.