Changeset 530


Ignore:
Timestamp:
Mar 5, 2009, 12:36:38 AM (11 years ago)
Author:
mnot@…
Message:

get rid of spurious MAYs

File:
1 edited

Legend:

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

    r528 r530  
    389389
    390390      <section anchor="response.cacheability" title="Response Cacheability">
    391         <t>A cache &MAY; store a response to any request, provided that: <list style="symbols">
     391        <t>A cache &MUST-NOT; store a response to any request, unless: <list style="symbols">
    392392                <t>The request method is defined as being cacheable, and</t>
    393393            <t>the "no-store" cache directive (see <xref target="header.cache-control" />) does not
     
    409409          title="Storing Partial and Incomplete Responses">
    410410          <t>A cache that receives an incomplete response (for example, with fewer bytes of data
    411             than specified in a Content-Length header) &MAY; store the response. However, the
    412             cache &MUST; treat this as a partial response &partial;. Partial responses
    413             &MAY; be combined as described in &combining-byte-ranges;; the result might be a
     411            than specified in a Content-Length header) can store the response, but &MUST;
     412            treat it as a partial response &partial;. Partial responses
     413            can be combined as described in &combining-byte-ranges;; the result might be a
    414414            full response or might still be partial. A cache &MUST-NOT; return a partial
    415415            response to a client without explicitly marking it as such using the 206 (Partial
     
    424424      <section anchor="constructing.responses.from.caches"
    425425        title="Constructing Responses from Caches">
    426         <t>For a presented request, a cache &MAY; return a stored response, provided
    427           that: <list style="symbols">
     426        <t>For a presented request, a cache &MUST-NOT; return a stored response, unless:
     427          <list style="symbols">
    428428            <t>The presented Request-URI and that of the stored response match (see
    429429              <cref>TBD</cref>), and</t>
     
    454454            <xref target="invalidation.after.updates.or.deletions" />.</t>
    455455        <t>Caches &MUST; use the most recent response (as determined by the Date header) when
    456           more than one suitable response is stored. They &MAY; also forward a request with
     456          more than one suitable response is stored. They can also forward a request with
    457457          "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to
    458458          use.</t>
     
    476476          explicit expiration times to responses in the belief that the entity is not likely to
    477477          change in a semantically significant way before the expiration time is reached.</t>
    478         <t>If an origin server wishes to force a cache to validate every request, it &MAY;
     478        <t>If an origin server wishes to force a cache to validate every request, it can
    479479          assign an explicit expiration time in the past. This means that the response is always
    480480          stale, so that caches should validate it before using it for subsequent requests. <cref>This wording may cause confusion, because the response may still be served stale.</cref></t>
     
    522522          <section anchor="heuristic.freshness" title="Calculating Heuristic Freshness">
    523523            <t>If no explicit expiration time is present in a stored response that has a status code
    524               of 200, 203, 206, 300, 301 or 410, a heuristic expiration time &MAY; be
     524              of 200, 203, 206, 300, 301 or 410, a heuristic expiration time can be
    525525              calculated. Heuristics &MUST-NOT; be used for other response status codes. </t>
    526526            <t> When a heuristic is used to calculate freshness lifetime, the cache &SHOULD;
     
    604604            have heuristic expiry calculated, but is not fresh according to the calculations in
    605605              <xref target="expiration.model" />.</t>
    606           <t>Caches &MAY; return a stale response if disconnected (i.e., it cannot contact
    607           the origin server or otherwise find a forward path) or explicitly allowed (e.g.,
    608             the max-stale request directive; see <xref target="cache-request-directive" />).</t>
    609606          <t>Caches &MUST-NOT; return a stale response if it is prohibited by an explicit
    610607            in-protocol directive (e.g., by a "no-store" or "no-cache" cache directive, a
     
    612609            "proxy-revalidate" cache-response-directive; see <xref target="cache-response-directive"
    613610             />). </t>
    614           <t>Otherwise, caches &SHOULD-NOT; return stale responses.</t>
     611          <t>Caches &SHOULD-NOT; return stale responses unless they are
     612          disconnected (i.e., it cannot contact the origin server or otherwise find a forward path)
     613          or otherwise explicitly allowed (e.g., the max-stale request directive; see <xref target="cache-request-directive" />)..</t>
    615614          <t>Stale responses &SHOULD; have a Warning header with the 110 warn-code (see <xref
    616615              target="header.warning" />). Likewise, the 112 warn-code &SHOULD; be sent on stale responses if
     
    10301029          <t>The Cache-Control header field can be extended through the use of one or more
    10311030            cache-extension tokens, each with an optional value. Informational extensions (those
    1032             that do not require a change in cache behavior) &MAY; be added without changing the
     1031            that do not require a change in cache behavior) can be added without changing the
    10331032            semantics of other directives. Behavioral extensions are designed to work by acting as
    10341033            modifiers to the existing base of cache directives. Both the new directive and the
     
    12011200</artwork></figure>
    12021201
    1203         <t>Multiple warnings &MAY; be attached to a response (either by the origin server or by
     1202        <t>Multiple warnings can be attached to a response (either by the origin server or by
    12041203          a cache), including multiple warnings with the same code number. For example, a server
    12051204          might provide the same warning with texts in both English and Basque.</t>
     
    12681267        </t>
    12691268        <t>199 Miscellaneous warning <list>
    1270             <t>The warning text &MAY; include arbitrary information to be presented to a human
     1269            <t>The warning text can include arbitrary information to be presented to a human
    12711270              user, or logged. A system receiving this warning &MUST-NOT; take any automated
    12721271              action, besides presenting the warning to the user.</t>
     
    12821281        </t>
    12831282        <t>299 Miscellaneous persistent warning <list>
    1284             <t>The warning text &MAY; include arbitrary information to be presented to a human
     1283            <t>The warning text can include arbitrary information to be presented to a human
    12851284              user, or logged. A system receiving this warning &MUST-NOT; take any automated
    12861285              action.</t>
Note: See TracChangeset for help on using the changeset viewer.