Ignore:
Timestamp:
Jun 11, 2012, 6:29:02 AM (7 years ago)
Author:
julian.reschke@…
Message:

bcp14 markup (editorial)

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p6-cache.html

    r1667 r1675  
    452452  }
    453453  @bottom-center {
    454        content: "Expires December 3, 2012";
     454       content: "Expires December 13, 2012";
    455455  }
    456456  @bottom-right {
     
    494494      <meta name="dct.creator" content="Reschke, J. F.">
    495495      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    496       <meta name="dct.issued" scheme="ISO8601" content="2012-06-01">
     496      <meta name="dct.issued" scheme="ISO8601" content="2012-06-11">
    497497      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    498498      <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 6 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
     
    520520            </tr>
    521521            <tr>
    522                <td class="left">Expires: December 3, 2012</td>
     522               <td class="left">Expires: December 13, 2012</td>
    523523               <td class="right">M. Nottingham, Editor</td>
    524524            </tr>
     
    537537            <tr>
    538538               <td class="left"></td>
    539                <td class="right">June 1, 2012</td>
     539               <td class="right">June 11, 2012</td>
    540540            </tr>
    541541         </tbody>
     
    567567         in progress”.
    568568      </p>
    569       <p>This Internet-Draft will expire on December 3, 2012.</p>
     569      <p>This Internet-Draft will expire on December 13, 2012.</p>
    570570      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    571571      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    11121112      </p>
    11131113      <p id="rfc.section.2.5.p.3">If the Content-Length, ETag and Last-Modified values of a HEAD response (when present) are the same as that in a selected
    1114          GET response (as per <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.8</a>), the cache SHOULD update the remaining headers in the stored response using the following rules:
     1114         GET response (as per <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.8</a>), the cache <em class="bcp14">SHOULD</em> update the remaining headers in the stored response using the following rules:
    11151115      </p>
    11161116      <ul>
     
    13381338            stale responses.
    13391339         </li>
    1340          <li>If the no-cache response directive specifies one or more field-names, then a cache MAY use the response to satisfy a subsequent
    1341             request, subject to any other restrictions on caching. However, any header fields in the response that have the field-name(s)
    1342             listed <em class="bcp14">MUST NOT</em> be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin
     1340         <li>If the no-cache response directive specifies one or more field-names, then a cache <em class="bcp14">MAY</em> use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, any header fields
     1341            in the response that have the field-name(s) listed <em class="bcp14">MUST NOT</em> be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin
    13431342            server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response.
    13441343         </li>
  • draft-ietf-httpbis/latest/p6-cache.xml

    r1667 r1675  
    986986   If the Content-Length, ETag and Last-Modified values of a HEAD response
    987987   (when present) are the same as that in a selected GET response (as per
    988    <xref target="caching.negotiated.responses"/>), the cache SHOULD update the
     988   <xref target="caching.negotiated.responses"/>), the cache &SHOULD; update the
    989989   remaining headers in the stored response using the following rules:
    990990   <list style="symbols">
     
    13991399      have been configured to return stale responses.</t>
    14001400      <t>If the no-cache response directive specifies one or more field-names,
    1401       then a cache MAY use the response to satisfy a subsequent request,
     1401      then a cache &MAY; use the response to satisfy a subsequent request,
    14021402      subject to any other restrictions on caching. However, any header fields
    14031403      in the response that have the field-name(s) listed &MUST-NOT; be sent
Note: See TracChangeset for help on using the changeset viewer.