Ignore:
Timestamp:
07/05/13 06:21:36 (10 years ago)
Author:
mnot@…
Message:

Alphabetise cache-control directives; see #469

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r2235 r2236  
    11651165<section title="Request Cache-Control Directives" anchor="cache-request-directive">
    11661166
     1167<section title="max-age" anchor="cache-request-directive.max-age">
     1168   <iref item="max-age (cache directive)" primary="true" />
     1169<t>
     1170   Argument syntax:
     1171   <list>
     1172      <t>
     1173        <x:ref>delta-seconds</x:ref> (see <xref target="delta-seconds"/>)
     1174      </t>
     1175   </list>
     1176</t>
     1177<t>
     1178   The "max-age" request directive indicates that the client is unwilling to
     1179   accept a response whose age is greater than the specified number of
     1180   seconds. Unless the max-stale request directive is also present, the
     1181   client is not willing to accept a stale response.
     1182</t>
     1183<t>
     1184   &Note; This directive uses the token form of the argument syntax;
     1185   e.g., 'max-age=5', not 'max-age="5"'. Senders &SHOULD-NOT; use the
     1186   quoted-string form.
     1187</t>
     1188</section>
     1189
     1190<section title="max-stale" anchor="cache-request-directive.max-stale">
     1191   <iref item="max-stale (cache directive)" primary="true" />
     1192<t>
     1193   Argument syntax:
     1194   <list>
     1195      <t>
     1196        <x:ref>delta-seconds</x:ref> (see <xref target="delta-seconds"/>)
     1197      </t>
     1198   </list>
     1199</t>
     1200<t>
     1201   The "max-stale" request directive indicates that the client is willing
     1202   to accept a response that has exceeded its freshness lifetime. If max-stale
     1203   is assigned a value, then the client is willing to accept a response
     1204   that has exceeded its freshness lifetime by no more than the specified
     1205   number of seconds. If no value is assigned to max-stale, then the client
     1206   is willing to accept a stale response of any age.
     1207</t>
     1208<t>
     1209   &Note; This directive uses the token form of the argument syntax;
     1210   e.g., 'max-stale=10', not 'max-stale="10"'. Senders &SHOULD-NOT; use the
     1211   quoted-string form.
     1212</t>
     1213</section>
     1214
     1215<section title="min-fresh" anchor="cache-request-directive.min-fresh">
     1216   <iref item="min-fresh (cache directive)" primary="true" />
     1217<t>
     1218   Argument syntax:
     1219   <list>
     1220      <t>
     1221        <x:ref>delta-seconds</x:ref> (see <xref target="delta-seconds"/>)
     1222      </t>
     1223   </list>
     1224</t>
     1225<t>
     1226   The "min-fresh" request directive indicates that the client is willing
     1227   to accept a response whose freshness lifetime is no less than its
     1228   current age plus the specified time in seconds. That is, the client
     1229   wants a response that will still be fresh for at least the specified
     1230   number of seconds.
     1231</t>
     1232<t>
     1233   &Note; This directive uses the token form of the argument syntax;
     1234   e.g., 'min-fresh=20', not 'min-fresh="20"'. Senders &SHOULD-NOT; use the
     1235   quoted-string form.
     1236</t>
     1237</section>
     1238
    11671239<section title="no-cache" anchor="cache-request-directive.no-cache">
    11681240   <iref item="no-cache (cache directive)" primary="true" />
    … …  
    11981270</section>
    11991271
    1200 <section title="max-age" anchor="cache-request-directive.max-age">
    1201    <iref item="max-age (cache directive)" primary="true" />
    1202 <t>
    1203    Argument syntax:
    1204    <list>
    1205       <t>
    1206         <x:ref>delta-seconds</x:ref> (see <xref target="delta-seconds"/>)
    1207       </t>
    1208    </list>
    1209 </t>
    1210 <t>
    1211    The "max-age" request directive indicates that the client is unwilling to
    1212    accept a response whose age is greater than the specified number of
    1213    seconds. Unless the max-stale request directive is also present, the
    1214    client is not willing to accept a stale response.
    1215 </t>
    1216 <t>
    1217    &Note; This directive uses the token form of the argument syntax;
    1218    e.g., 'max-age=5', not 'max-age="5"'. Senders &SHOULD-NOT; use the
    1219    quoted-string form.
    1220 </t>
    1221 </section>
    1222 
    1223 <section title="max-stale" anchor="cache-request-directive.max-stale">
    1224    <iref item="max-stale (cache directive)" primary="true" />
    1225 <t>
    1226    Argument syntax:
    1227    <list>
    1228       <t>
    1229         <x:ref>delta-seconds</x:ref> (see <xref target="delta-seconds"/>)
    1230       </t>
    1231    </list>
    1232 </t>
    1233 <t>
    1234    The "max-stale" request directive indicates that the client is willing
    1235    to accept a response that has exceeded its freshness lifetime. If max-stale
    1236    is assigned a value, then the client is willing to accept a response
    1237    that has exceeded its freshness lifetime by no more than the specified
    1238    number of seconds. If no value is assigned to max-stale, then the client
    1239    is willing to accept a stale response of any age.
    1240 </t>
    1241 <t>
    1242    &Note; This directive uses the token form of the argument syntax;
    1243    e.g., 'max-stale=10', not 'max-stale="10"'. Senders &SHOULD-NOT; use the
    1244    quoted-string form.
    1245 </t>
    1246 </section>
    1247 
    1248 <section title="min-fresh" anchor="cache-request-directive.min-fresh">
    1249    <iref item="min-fresh (cache directive)" primary="true" />
    1250 <t>
    1251    Argument syntax:
    1252    <list>
    1253       <t>
    1254         <x:ref>delta-seconds</x:ref> (see <xref target="delta-seconds"/>)
    1255       </t>
    1256    </list>
    1257 </t>
    1258 <t>
    1259    The "min-fresh" request directive indicates that the client is willing
    1260    to accept a response whose freshness lifetime is no less than its
    1261    current age plus the specified time in seconds. That is, the client
    1262    wants a response that will still be fresh for at least the specified
    1263    number of seconds.
    1264 </t>
    1265 <t>
    1266    &Note; This directive uses the token form of the argument syntax;
    1267    e.g., 'min-fresh=20', not 'min-fresh="20"'. Senders &SHOULD-NOT; use the
    1268    quoted-string form.
    1269 </t>
    1270 </section>
    1271 
    12721272<section title="no-transform" anchor="cache-request-directive.no-transform">
    12731273   <iref item="no-transform (cache directive)" primary="true" />
    … …  
    12971297   <x:anchor-alias value="cache-response-directive" />
    12981298
    1299 <section title="public" anchor="cache-response-directive.public">
    1300    <iref item="public (cache directive)" primary="true" />
    1301 <t>
    1302    The "public" response directive indicates that any cache &MAY; store the
    1303    response, even if the response would normally be non-cacheable or cacheable
    1304    only within a non-shared cache. (See <xref
    1305    target="caching.authenticated.responses"/> for additional details related
    1306    to the use of public in response to a request containing
    1307    <x:ref>Authorization</x:ref>, and <xref target="response.cacheability"/>
    1308    for details of how public affects responses that would normally not be
    1309    stored, due to their status codes not being defined as cacheable.)
    1310 </t>
    1311 </section>
    1312 
    1313 <section title="private" anchor="cache-response-directive.private">
    1314    <iref item="private (cache directive)" primary="true" />
    1315 <t>
    1316    Argument syntax:
    1317    <list>
    1318       <t>
    1319         #<x:ref>field-name</x:ref>
    1320       </t>
    1321    </list>
    1322 </t>
    1323 <t>
    1324    The "private" response directive indicates that the response message is
    1325    intended for a single user and &MUST-NOT; be stored by a shared cache. A
    1326    private cache &MAY; store the response and reuse it for later requests,
    1327    even if the response would normally be non-cacheable.
    1328 </t>
    1329 <t>
    1330    If the private response directive specifies one or more field-names,
    1331    this requirement is limited to the field-values associated with the
    1332    listed response header fields. That is, a shared cache &MUST-NOT; store
    1333    the specified field-names(s), whereas it &MAY; store the remainder of the
    1334    response message.
    1335 </t>
    1336 <t>
    1337    The field-names given are not limited to the set of header
    1338    fields defined by this specification. Field names are case-insensitive.
    1339 </t>
    1340 <t>
    1341    &Note; This usage of the word "private" only controls
    1342    where the response can be stored; it cannot ensure the privacy of the
    1343    message content. Also, private response directives with field-names are
    1344    often handled by implementations as if an unqualified private directive
    1345    was received; i.e., the special handling for the qualified form is not
    1346    widely implemented.
    1347 </t>
    1348 <t>
    1349    &Note; This directive uses the quoted-string form of the argument syntax.
    1350    Senders &SHOULD-NOT; use the token form (even if quoting appears not to be
    1351    needed for single-entry lists).
     1299<section title="must-revalidate" anchor="cache-response-directive.must-revalidate">
     1300   <iref item="must-revalidate (cache directive)" primary="true" />
     1301<t>
     1302   The "must-revalidate" response directive indicates that once it has
     1303   become stale, a cache &MUST-NOT; use the response to satisfy subsequent
     1304   requests without successful validation on the origin server.
     1305</t>
     1306<t>
     1307   The must-revalidate directive is necessary to support reliable
     1308   operation for certain protocol features. In all circumstances a
     1309   cache &MUST; obey the must-revalidate directive; in particular,
     1310   if a cache cannot reach the origin server for any reason, it &MUST;
     1311   generate a <x:ref>504 (Gateway Timeout)</x:ref> response.
     1312</t>
     1313<t>
     1314   The must-revalidate directive ought to be used by servers if and only
     1315   if failure to validate a request on the representation could result in
     1316   incorrect operation, such as a silently unexecuted financial
     1317   transaction.
    13521318</t>
    13531319</section>
    … …  
    14171383</section>
    14181384
    1419 <section title="must-revalidate" anchor="cache-response-directive.must-revalidate">
    1420    <iref item="must-revalidate (cache directive)" primary="true" />
    1421 <t>
    1422    The "must-revalidate" response directive indicates that once it has
    1423    become stale, a cache &MUST-NOT; use the response to satisfy subsequent
    1424    requests without successful validation on the origin server.
    1425 </t>
    1426 <t>
    1427    The must-revalidate directive is necessary to support reliable
    1428    operation for certain protocol features. In all circumstances a
    1429    cache &MUST; obey the must-revalidate directive; in particular,
    1430    if a cache cannot reach the origin server for any reason, it &MUST;
    1431    generate a <x:ref>504 (Gateway Timeout)</x:ref> response.
    1432 </t>
    1433 <t>
    1434    The must-revalidate directive ought to be used by servers if and only
    1435    if failure to validate a request on the representation could result in
    1436    incorrect operation, such as a silently unexecuted financial
    1437    transaction.
     1385<section title="no-transform" anchor="cache-response-directive.no-transform">
     1386   <iref item="no-transform (cache directive)" primary="true" />
     1387<t>
     1388   The "no-transform" response directive indicates that an intermediary
     1389   (regardless of whether it implements a cache) &MUST-NOT; transform the
     1390   payload, as defined in &transformations;.
     1391</t>
     1392</section>
     1393
     1394<section title="public" anchor="cache-response-directive.public">
     1395   <iref item="public (cache directive)" primary="true" />
     1396<t>
     1397   The "public" response directive indicates that any cache &MAY; store the
     1398   response, even if the response would normally be non-cacheable or cacheable
     1399   only within a non-shared cache. (See <xref
     1400   target="caching.authenticated.responses"/> for additional details related
     1401   to the use of public in response to a request containing
     1402   <x:ref>Authorization</x:ref>, and <xref target="response.cacheability"/>
     1403   for details of how public affects responses that would normally not be
     1404   stored, due to their status codes not being defined as cacheable.)
     1405</t>
     1406</section>
     1407
     1408<section title="private" anchor="cache-response-directive.private">
     1409   <iref item="private (cache directive)" primary="true" />
     1410<t>
     1411   Argument syntax:
     1412   <list>
     1413      <t>
     1414        #<x:ref>field-name</x:ref>
     1415      </t>
     1416   </list>
     1417</t>
     1418<t>
     1419   The "private" response directive indicates that the response message is
     1420   intended for a single user and &MUST-NOT; be stored by a shared cache. A
     1421   private cache &MAY; store the response and reuse it for later requests,
     1422   even if the response would normally be non-cacheable.
     1423</t>
     1424<t>
     1425   If the private response directive specifies one or more field-names,
     1426   this requirement is limited to the field-values associated with the
     1427   listed response header fields. That is, a shared cache &MUST-NOT; store
     1428   the specified field-names(s), whereas it &MAY; store the remainder of the
     1429   response message.
     1430</t>
     1431<t>
     1432   The field-names given are not limited to the set of header
     1433   fields defined by this specification. Field names are case-insensitive.
     1434</t>
     1435<t>
     1436   &Note; This usage of the word "private" only controls
     1437   where the response can be stored; it cannot ensure the privacy of the
     1438   message content. Also, private response directives with field-names are
     1439   often handled by implementations as if an unqualified private directive
     1440   was received; i.e., the special handling for the qualified form is not
     1441   widely implemented.
     1442</t>
     1443<t>
     1444   &Note; This directive uses the quoted-string form of the argument syntax.
     1445   Senders &SHOULD-NOT; use the token form (even if quoting appears not to be
     1446   needed for single-entry lists).
    14381447</t>
    14391448</section>
    … …  
    14911500   e.g., 's-maxage=10', not 's-maxage="10"'. Senders &SHOULD-NOT; use the
    14921501   quoted-string form.
    1493 </t>
    1494 </section>
    1495 
    1496 <section title="no-transform" anchor="cache-response-directive.no-transform">
    1497    <iref item="no-transform (cache directive)" primary="true" />
    1498 <t>
    1499    The "no-transform" response directive indicates that an intermediary
    1500    (regardless of whether it implements a cache) &MUST-NOT; transform the
    1501    payload, as defined in &transformations;.
    15021502</t>
    15031503</section>
Note: See TracChangeset for help on using the changeset viewer.