Ignore:
Timestamp:
Jul 9, 2012, 4:44:03 PM (7 years ago)
Author:
mnot@…
Message:

Re-org caching sections

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p6-cache.xml

    r1746 r1751  
    416416</section>
    417417
    418 <section anchor="caching.overview" title="Cache Operation">
     418<section anchor="caching.overview" title="Overview of Cache Operation">
    419419<iref item="cache entry" />
    420420<iref item="cache key" />
    … …  
    453453   fields (<xref target="caching.negotiated.responses"/>).
    454454</t>
    455 
    456 <section anchor="response.cacheability" title="Response Cacheability">
     455</section>
     456
     457<section anchor="response.cacheability" title="Storing Responses in Caches">
    457458<t>
    458459   A cache &MUST-NOT; store a response to any request, unless:
    … …  
    503504   prohibited from storing such responses.
    504505</t>
     506
     507<section anchor="incomplete.responses" title="Storing Incomplete Responses">
    505508<t>
    506509   A response message is considered complete when all of the octets indicated
    … …  
    526529   using the <x:ref>206 (Partial Content)</x:ref> status code.
    527530</t>
     531</section>
     532
     533
     534<section anchor="caching.authenticated.responses"
     535   title="Storing Responses to Authenticated Requests">
     536<t>
     537   A shared cache &MUST-NOT; use a cached response to a request with an
     538   <x:ref>Authorization</x:ref> header field (&header-authorization;) to
     539   satisfy any subsequent request unless a cache directive that allows such
     540   responses to be stored is present in the response.
     541</t>
     542
     543<t>
     544   In this specification, the following <x:ref>Cache-Control</x:ref> response
     545   directives (<xref target="cache-response-directive"/>) have such an effect:
     546   must-revalidate, public, s-maxage.
     547</t>
     548
     549<t>
     550   Note that cached responses that contain the "must-revalidate" and/or
     551   "s-maxage" response directives are not allowed to be served stale (<xref
     552   target="serving.stale.responses"/>) by shared caches. In particular, a
     553   response with either "max-age=0, must-revalidate" or "s-maxage=0" cannot be
     554   used to satisfy a subsequent request without revalidating it on the origin
     555   server.
     556</t>
     557</section>
    528558</section>
    529559
    … …  
    594624</t>
    595625
    596 </section>
    597626
    598627<section anchor="expiration.model" title="Freshness Model">
    … …  
    682711   responses that have invalid freshness information to be stale.
    683712</t>
     713</section>
    684714
    685715<section anchor="heuristic.freshness" title="Calculating Heuristic Freshness">
    … …  
    717747   </t>
    718748</x:note>
    719 </section>
    720749</section>
    721750
    … …  
    9871016</section>
    9881017
    989 <section anchor="head.effects" title="Updating Caches with HEAD Responses">
    990 <t>
    991    A response to the HEAD method is identical to what an equivalent request
    992    made with a GET would have been, except it lacks a body. This property
    993    of HEAD responses is used to both invalidate and update cached GET
    994    responses.
    995 </t>
    996 <t>
    997    If one or more stored GET responses can be selected (as per <xref
    998    target="caching.negotiated.responses"/>) for a HEAD request, and the
    999    <x:ref>Content-Length</x:ref>, <x:ref>ETag</x:ref> or
    1000    <x:ref>Last-Modified</x:ref> value of a HEAD response differs from that in a
    1001    selected GET response, the cache &MUST; consider that selected response to
    1002    be stale.
    1003 </t>
    1004 <t>
    1005    If the <x:ref>Content-Length</x:ref>, <x:ref>ETag</x:ref> and
    1006    <x:ref>Last-Modified</x:ref> values of a HEAD response (when present) are
    1007    the same as that in a selected GET response (as per
    1008    <xref target="caching.negotiated.responses"/>), the cache &SHOULD; update
    1009    the remaining headers in the stored response using the following rules:
    1010    <list style="symbols">
    1011       <t>delete any <x:ref>Warning</x:ref> header fields in the stored response
    1012          with warn-code 1xx (see <xref target="header.warning" />);</t>
    1013       <t>retain any <x:ref>Warning</x:ref> header fields in the stored response
    1014          with warn-code 2xx; and,</t>
    1015       <t>use other header fields provided in the response to replace
    1016          all instances of the corresponding header fields in the stored
    1017          response.</t>
    1018    </list>
    1019 </t>
    1020 
    1021 </section>
    1022 
    1023 <section anchor="invalidation.after.updates.or.deletions"
    1024    title="Request Methods that Invalidate">
    1025 <t>
    1026    Because unsafe request methods (&safe-methods;) such as PUT, POST or DELETE
    1027    have the potential for changing state on the origin server, intervening
    1028    caches can use them to keep their contents up-to-date.
    1029 </t>
    1030 <t>
    1031    A cache &MUST; invalidate the effective Request URI
    1032    (&effective-request-uri;) as well as the URI(s) in the
    1033    <x:ref>Location</x:ref> and <x:ref>Content-Location</x:ref> response header
    1034    fields (if present) when a non-error response to a request with an unsafe
    1035    method is received.
    1036 </t>
    1037 <t>
    1038    However, a cache &MUST-NOT; invalidate a URI from a <x:ref>Location</x:ref>
    1039    or <x:ref>Content-Location</x:ref> response header field if the host part of
    1040    that URI differs from the host part in the effective request URI
    1041    (&effective-request-uri;). This helps prevent denial of service attacks.
    1042 </t>
    1043 <t>
    1044    A cache &MUST; invalidate the effective request URI
    1045    (&effective-request-uri;) when it receives a non-error response
    1046    to a request with a method whose safety is unknown.
    1047 </t>
    1048 <t>
    1049    Here, a "non-error response" is one with a <x:ref>2xx (Successful)</x:ref>
    1050    or <x:ref>3xx (Redirection)</x:ref> status code. "Invalidate" means that
    1051    the cache will either remove all stored responses related to the effective
    1052    request URI, or will mark these as "invalid" and in need of a mandatory
    1053    validation before they can be returned in response to a subsequent request.
    1054 </t>
    1055 <t>
    1056    Note that this does not guarantee that all appropriate responses are
    1057    invalidated. For example, the request that caused the change at the origin
    1058    server might not have gone through the cache where a response is stored.
    1059 </t>
    1060 </section>
    1061 
    1062 <section anchor="caching.authenticated.responses"
    1063    title="Shared Caching of Authenticated Responses">
    1064 <t>
    1065    A shared cache &MUST-NOT; use a cached response to a request with an
    1066    <x:ref>Authorization</x:ref> header field (&header-authorization;) to
    1067    satisfy any subsequent request unless a cache directive that allows such
    1068    responses to be stored is present in the response.
    1069 </t>
    1070 
    1071 <t>
    1072    In this specification, the following <x:ref>Cache-Control</x:ref> response
    1073    directives (<xref target="cache-response-directive"/>) have such an effect:
    1074    must-revalidate, public, s-maxage.
    1075 </t>
    1076 
    1077 <t>
    1078    Note that cached responses that contain the "must-revalidate" and/or
    1079    "s-maxage" response directives are not allowed to be served stale (<xref
    1080    target="serving.stale.responses"/>) by shared caches. In particular, a
    1081    response with either "max-age=0, must-revalidate" or "s-maxage=0" cannot be
    1082    used to satisfy a subsequent request without revalidating it on the origin
    1083    server.
    1084 </t>
    1085 </section>
    1086 
    10871018<section anchor="caching.negotiated.responses"
    1088    title="Caching Negotiated Responses">
     1019   title="Using Negotiated Responses">
    10891020<t>
    10901021   When a cache receives a request that can be satisfied by a stored response
    … …  
    11421073</section>
    11431074
     1075
    11441076<section anchor="combining.responses" title="Combining Partial Content">
    11451077<t>
    … …  
    11661098</t>
    11671099</section>
    1168 
    1169 
    1170 </section>
     1100</section>
     1101
     1102
     1103<section anchor="head.effects" title="Updating Caches with HEAD Responses">
     1104<t>
     1105   A response to the HEAD method is identical to what an equivalent request
     1106   made with a GET would have been, except it lacks a body. This property
     1107   of HEAD responses is used to both invalidate and update cached GET
     1108   responses.
     1109</t>
     1110<t>
     1111   If one or more stored GET responses can be selected (as per <xref
     1112   target="caching.negotiated.responses"/>) for a HEAD request, and the
     1113   <x:ref>Content-Length</x:ref>, <x:ref>ETag</x:ref> or
     1114   <x:ref>Last-Modified</x:ref> value of a HEAD response differs from that in a
     1115   selected GET response, the cache &MUST; consider that selected response to
     1116   be stale.
     1117</t>
     1118<t>
     1119   If the <x:ref>Content-Length</x:ref>, <x:ref>ETag</x:ref> and
     1120   <x:ref>Last-Modified</x:ref> values of a HEAD response (when present) are
     1121   the same as that in a selected GET response (as per
     1122   <xref target="caching.negotiated.responses"/>), the cache &SHOULD; update
     1123   the remaining headers in the stored response using the following rules:
     1124   <list style="symbols">
     1125      <t>delete any <x:ref>Warning</x:ref> header fields in the stored response
     1126         with warn-code 1xx (see <xref target="header.warning" />);</t>
     1127      <t>retain any <x:ref>Warning</x:ref> header fields in the stored response
     1128         with warn-code 2xx; and,</t>
     1129      <t>use other header fields provided in the response to replace
     1130         all instances of the corresponding header fields in the stored
     1131         response.</t>
     1132   </list>
     1133</t>
     1134
     1135</section>
     1136
     1137
     1138<section anchor="invalidation.after.updates.or.deletions"
     1139   title="Request Methods that Invalidate">
     1140<t>
     1141   Because unsafe request methods (&safe-methods;) such as PUT, POST or DELETE
     1142   have the potential for changing state on the origin server, intervening
     1143   caches can use them to keep their contents up-to-date.
     1144</t>
     1145<t>
     1146   A cache &MUST; invalidate the effective Request URI
     1147   (&effective-request-uri;) as well as the URI(s) in the
     1148   <x:ref>Location</x:ref> and <x:ref>Content-Location</x:ref> response header
     1149   fields (if present) when a non-error response to a request with an unsafe
     1150   method is received.
     1151</t>
     1152<t>
     1153   However, a cache &MUST-NOT; invalidate a URI from a <x:ref>Location</x:ref>
     1154   or <x:ref>Content-Location</x:ref> response header field if the host part of
     1155   that URI differs from the host part in the effective request URI
     1156   (&effective-request-uri;). This helps prevent denial of service attacks.
     1157</t>
     1158<t>
     1159   A cache &MUST; invalidate the effective request URI
     1160   (&effective-request-uri;) when it receives a non-error response
     1161   to a request with a method whose safety is unknown.
     1162</t>
     1163<t>
     1164   Here, a "non-error response" is one with a <x:ref>2xx (Successful)</x:ref>
     1165   or <x:ref>3xx (Redirection)</x:ref> status code. "Invalidate" means that
     1166   the cache will either remove all stored responses related to the effective
     1167   request URI, or will mark these as "invalid" and in need of a mandatory
     1168   validation before they can be returned in response to a subsequent request.
     1169</t>
     1170<t>
     1171   Note that this does not guarantee that all appropriate responses are
     1172   invalidated. For example, the request that caused the change at the origin
     1173   server might not have gone through the cache where a response is stored.
     1174</t>
     1175</section>
     1176
     1177
     1178
    11711179
    11721180<section anchor="header.field.definitions" title="Header Field Definitions">
Note: See TracChangeset for help on using the changeset viewer.