Changeset 1746


Ignore:
Timestamp:
Jul 9, 2012, 12:51:48 AM (7 years ago)
Author:
mnot@…
Message:

rewrap some long lines in source

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r1745 r1746  
    406406   If an implementation receives a delta-seconds value larger than the largest
    407407   positive integer it can represent, or if any of its subsequent calculations
    408    overflows, it &MUST; consider the value to be 2147483648 (2<x:sup>31</x:sup>).
    409    Recipients parsing a delta-seconds value &MUST; use an arithmetic type of
    410    at least 31 bits of range, and senders &MUST-NOT; send delta-seconds with a
    411    value greater than 2147483648.
     408   overflows, it &MUST; consider the value to be 2147483648
     409   (2<x:sup>31</x:sup>). Recipients parsing a delta-seconds value &MUST; use
     410   an arithmetic type of at least 31 bits of range, and senders &MUST-NOT;
     411   send delta-seconds with a value greater than 2147483648.
    412412</t>
    413413</section>
    … …  
    431431<t>
    432432   Each <x:dfn>cache entry</x:dfn> consists of a cache key and one or more
    433    HTTP responses corresponding to prior requests that used the same key.
    434    The most common form of cache entry is a successful result of a retrieval
    435    request: i.e., a <x:ref>200 (OK)</x:ref> response containing a representation
    436    of the resource identified by the request target.  However, it is also possible
    437    to cache negative results (e.g., <x:ref>404 (Not Found)</x:ref>, incomplete results
    438    (e.g., <x:ref>206 (Partial Content)</x:ref>), and responses to safe methods other than
    439    GET if the method's definition allows such caching and defines something
    440    suitable for use as a cache key.
     433   HTTP responses corresponding to prior requests that used the same key. The
     434   most common form of cache entry is a successful result of a retrieval
     435   request: i.e., a <x:ref>200 (OK)</x:ref> response containing a
     436   representation of the resource identified by the request target. However,
     437   it is also possible to cache negative results (e.g., <x:ref>404 (Not
     438   Found)</x:ref>, incomplete results (e.g., <x:ref>206 (Partial
     439   Content)</x:ref>), and responses to safe methods other than GET if the
     440   method's definition allows such caching and defines something suitable for
     441   use as a cache key.
    441442</t>
    442443<t>
    … …  
    466467      target="cache-response-directive" />) does not appear in the response, if
    467468      the cache is shared, and</t>
    468       <t>the <x:ref>Authorization</x:ref> header field (see &header-authorization;) does not
    469       appear in the request, if the cache is shared, unless the response
    470       explicitly allows it (see <xref target="caching.authenticated.responses"
    471       />), and</t>
     469      <t>the <x:ref>Authorization</x:ref> header field (see
     470      &header-authorization;) does not appear in the request, if the cache is
     471      shared, unless the response explicitly allows it (see <xref
     472      target="caching.authenticated.responses" />), and</t>
    472473      <t>the response either:
    473474         <list style="symbols">
    … …  
    503504</t>
    504505<t>
    505    A response message is considered complete when all of the octets
    506    indicated by the message framing (&messaging;) are received
    507    prior to the connection being closed. If the request is GET, the response
    508    status is <x:ref>200 (OK)</x:ref>, and the entire
    509    response header block has been received, a cache &MAY; store an incomplete
    510    response message body if the cache entry is recorded as incomplete.
    511    Likewise, a <x:ref>206 (Partial Content)</x:ref> response &MAY; be stored as if it were
    512    an incomplete <x:ref>200 (OK)</x:ref> cache entry.  However, a cache &MUST-NOT; store
    513    incomplete or partial content responses if it does not support the
    514    <x:ref>Range</x:ref> and <x:ref>Content-Range</x:ref> header fields or if it
    515    does not understand the range units used in those fields.
     506   A response message is considered complete when all of the octets indicated
     507   by the message framing (&messaging;) are received prior to the connection
     508   being closed. If the request is GET, the response status is <x:ref>200
     509   (OK)</x:ref>, and the entire response header block has been received, a
     510   cache &MAY; store an incomplete response message body if the cache entry is
     511   recorded as incomplete. Likewise, a <x:ref>206 (Partial Content)</x:ref>
     512   response &MAY; be stored as if it were an incomplete <x:ref>200
     513   (OK)</x:ref> cache entry. However, a cache &MUST-NOT; store incomplete or
     514   partial content responses if it does not support the <x:ref>Range</x:ref>
     515   and <x:ref>Content-Range</x:ref> header fields or if it does not understand
     516   the range units used in those fields.
    516517</t>
    517518<t>
    518519   A cache &MAY; complete a stored incomplete response by making a subsequent
    519520   range request (&partial;) and combining the successful response with the
    520    stored entry, as defined in <xref target="combining.responses"/>.
    521    A cache &MUST-NOT; use an incomplete response to answer requests
    522    unless the response has been made complete or the request is partial and
    523    specifies a range that is wholly within the incomplete response.
    524    A cache &MUST-NOT; send a partial response to a client without explicitly
    525    marking it as such using the <x:ref>206 (Partial Content)</x:ref> status code.
     521   stored entry, as defined in <xref target="combining.responses"/>. A cache
     522   &MUST-NOT; use an incomplete response to answer requests unless the
     523   response has been made complete or the request is partial and specifies a
     524   range that is wholly within the incomplete response. A cache &MUST-NOT;
     525   send a partial response to a client without explicitly marking it as such
     526   using the <x:ref>206 (Partial Content)</x:ref> status code.
    526527</t>
    527528</section>
    … …  
    570571</t>
    571572<t>
    572    A cache &MUST; write through requests with methods that are unsafe 
    573    (&safe-methods;) to the origin server; i.e., a cache is not allowed to generate
    574    a reply to such a request before having forwarded the request and having
    575    received a corresponding response.
     573   A cache &MUST; write through requests with methods that are unsafe
     574   (&safe-methods;) to the origin server; i.e., a cache is not allowed to
     575   generate a reply to such a request before having forwarded the request and
     576   having received a corresponding response.
    576577</t>
    577578<t>
    … …  
    586587</t>
    587588<t>
    588    A cache that does not have a clock available &MUST-NOT; use stored responses
    589    without revalidating them on every use. A cache, especially a shared
    590    cache, &SHOULD; use a mechanism, such as NTP <xref target="RFC1305"/>, to
    591    synchronize its clock with a reliable external standard.
     589   A cache that does not have a clock available &MUST-NOT; use stored
     590   responses without revalidating them on every use. A cache, especially a
     591   shared cache, &SHOULD; use a mechanism, such as NTP <xref
     592   target="RFC1305"/>, to synchronize its clock with a reliable external
     593   standard.
    592594</t>
    593595
    … …  
    602604<t>
    603605   The primary mechanism for determining freshness is for an origin server to
    604    provide an explicit expiration time in the future, using either the <x:ref>Expires</x:ref>
    605    header field (<xref target="header.expires" />) or the max-age response cache
    606    directive (<xref target="cache-response-directive" />). Generally, origin
    607    servers will assign future explicit expiration times to responses in the
    608    belief that the representation is not likely to change in a semantically
    609    significant way before the expiration time is reached.
     606   provide an explicit expiration time in the future, using either the
     607   <x:ref>Expires</x:ref> header field (<xref target="header.expires" />) or
     608   the max-age response cache directive (<xref
     609   target="cache-response-directive" />). Generally, origin servers will
     610   assign future explicit expiration times to responses in the belief that the
     611   representation is not likely to change in a semantically significant way
     612   before the expiration time is reached.
    610613</t>
    611614<t>
    … …  
    617620</t>
    618621<t>
    619    Since origin servers do not always provide explicit expiration times,
    620    a cache &MAY; assign a heuristic expiration time when an explicit time is not
    621    specified, employing algorithms that use other header field values (such as the
    622    <x:ref>Last-Modified</x:ref> time) to estimate a plausible expiration time.
    623    This specification does not provide specific algorithms, but does impose
    624    worst-case constraints on their results.
     622   Since origin servers do not always provide explicit expiration times, a
     623   cache &MAY; assign a heuristic expiration time when an explicit time is not
     624   specified, employing algorithms that use other header field values (such as
     625   the <x:ref>Last-Modified</x:ref> time) to estimate a plausible expiration
     626   time. This specification does not provide specific algorithms, but does
     627   impose worst-case constraints on their results.
    625628</t>
    626629<figure>
    … …  
    684687   If no explicit expiration time is present in a stored response that has a
    685688   status code whose definition allows heuristic freshness to be used
    686    (including the following in &status-codes;: <x:ref>200 (OK)</x:ref>, <x:ref>203
    687    (Non-Authoritative Information)</x:ref>, <x:ref>206 (Partial Content)</x:ref>,
    688    <x:ref>300 (Multiple Choices)</x:ref>, <x:ref>301 (Moved Permanently)</x:ref> and
    689    <x:ref>410 (Gone)</x:ref>), a cache &MAY; calculate a heuristic expiration time. A cache &MUST-NOT;
    690    use heuristics to determine freshness for responses with status codes that do
    691    not explicitly allow it.
     689   (including the following in &status-codes;: <x:ref>200 (OK)</x:ref>,
     690   <x:ref>203 (Non-Authoritative Information)</x:ref>, <x:ref>206 (Partial
     691   Content)</x:ref>, <x:ref>300 (Multiple Choices)</x:ref>, <x:ref>301 (Moved
     692   Permanently)</x:ref> and <x:ref>410 (Gone)</x:ref>), a cache &MAY;
     693   calculate a heuristic expiration time. A cache &MUST-NOT; use heuristics to
     694   determine freshness for responses with status codes that do not explicitly
     695   allow it.
    692696</t>
    693697<t>
    … …  
    720724   HTTP/1.1 uses the <x:ref>Age</x:ref> header field to convey the estimated
    721725   age of the response message when obtained from a cache. The Age field value
    722    is the cache's estimate of the amount of time since the response was generated or
    723    validated by the origin server. In essence, the Age value is the sum of the
    724    time that the response has been resident in each of the caches along the
    725    path from the origin server, plus the amount of time it has been in transit
    726    along network paths.
     726   is the cache's estimate of the amount of time since the response was
     727   generated or validated by the origin server. In essence, the Age value is
     728   the sum of the time that the response has been resident in each of the
     729   caches along the path from the origin server, plus the amount of time it
     730   has been in transit along network paths.
    727731</t>
    728732<t>
    … …  
    745749         HTTP/1.1 requires origin servers to send a <x:ref>Date</x:ref> header
    746750         field, if possible, with every response, giving the time at which the
    747          response was generated. The term "date_value" denotes the value of the
    748          Date header field, in a form appropriate for arithmetic operations. See
    749          &header-date; for the definition of the Date header field, and for
    750          requirements regarding responses without it.
     751         response was generated. The term "date_value" denotes the value of
     752         the Date header field, in a form appropriate for arithmetic
     753         operations. See &header-date; for the definition of the Date header
     754         field, and for requirements regarding responses without it.
    751755      </t>
    752756   </list>
    … …  
    876880<t>
    877881   If a cache receives a first-hand response (either an entire response, or a
    878    <x:ref>304 (Not Modified)</x:ref> response) that it would normally forward to the
    879    requesting client, and the received response is no longer fresh, the cache
    880    can forward it to the requesting client without adding a new <x:ref>Warning</x:ref>
    881    (but without removing any existing Warning header fields). A cache shouldn't
    882    attempt to validate a response simply because that response became stale in
    883    transit.
     882   <x:ref>304 (Not Modified)</x:ref> response) that it would normally forward
     883   to the requesting client, and the received response is no longer fresh, the
     884   cache can forward it to the requesting client without adding a new
     885   <x:ref>Warning</x:ref> (but without removing any existing Warning header
     886   fields). A cache shouldn't attempt to validate a response simply because
     887   that response became stale in transit.
    884888</t>
    885889</section>
    … …  
    912916</t>
    913917
    914 <t>Cache handling of a response to a conditional request is dependent upon its status code:</t>
     918<t>Cache handling of a response to a conditional request is dependent upon its
     919status code:</t>
    915920
    916921<t>
    917922   <list style="symbols">
    918923      <t>
    919          A <x:ref>304 (Not Modified)</x:ref> response status code indicates that the stored
    920          response can be updated and reused; see <xref
     924         A <x:ref>304 (Not Modified)</x:ref> response status code indicates
     925         that the stored response can be updated and reused; see <xref
    921926         target="freshening.responses"/>.
    922927      </t>
    … …  
    932937         forward this response to the requesting client, or act as if the
    933938         server failed to respond. In the latter case, it can return a
    934          previously stored response (see <xref target="serving.stale.responses" />).
     939         previously stored response (see <xref
     940         target="serving.stale.responses" />).
    935941      </t>
    936942   </list>
    … …  
    939945<section anchor="freshening.responses" title="Freshening Responses with 304 Not Modified">
    940946<t>
    941    When a cache receives a <x:ref>304 (Not Modified)</x:ref> response and already has one
    942    or more stored <x:ref>200 (OK)</x:ref> responses for the same cache key, the cache needs
    943    to identify which of the stored responses are updated by this new response
    944    and then update the stored response(s) with the new information provided in
    945    the <x:ref>304</x:ref> response.
     947   When a cache receives a <x:ref>304 (Not Modified)</x:ref> response and
     948   already has one or more stored <x:ref>200 (OK)</x:ref> responses for the
     949   same cache key, the cache needs to identify which of the stored responses
     950   are updated by this new response and then update the stored response(s)
     951   with the new information provided in the <x:ref>304</x:ref> response.
    946952   <list style="symbols">
    947953    <t>
    … …  
    10231029</t>
    10241030<t>
    1025    A cache &MUST; invalidate the effective Request URI
    1026    (&effective-request-uri;) as well as the URI(s) in the <x:ref>Location</x:ref>
    1027    and <x:ref>Content-Location</x:ref> response header fields (if present) when
    1028    a non-error response to a request with an unsafe method is received.
     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.
    10291036</t>
    10301037<t>
    … …  
    10401047</t>
    10411048<t>
    1042    Here, a "non-error response" is one with a <x:ref>2xx (Successful)</x:ref> or
    1043    <x:ref>3xx (Redirection)</x:ref> status code.
    1044    "Invalidate" means that the cache will either remove all stored
    1045    responses related to the effective request URI, or will mark these as
    1046    "invalid" and in need of a mandatory validation before they can be returned
    1047    in response to a subsequent request.
     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.
    10481054</t>
    10491055<t>
    … …  
    10581064<t>
    10591065   A shared cache &MUST-NOT; use a cached response to a request with an
    1060    <x:ref>Authorization</x:ref> header field (&header-authorization;) to satisfy any subsequent
    1061    request unless a cache directive that allows such responses to be stored is
    1062    present in the response.
     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.
    10631069</t>
    10641070
    … …  
    10851091   that has a <x:ref>Vary</x:ref> header field (<xref target="header.vary"/>),
    10861092   it &MUST-NOT; use that response unless all of the selecting header fields
    1087    nominated by the Vary header field match in both the original request (i.e.,
    1088    that associated with the stored response), and the presented request.
     1093   nominated by the Vary header field match in both the original request
     1094   (i.e., that associated with the stored response), and the presented
     1095   request.
    10891096</t>
    10901097<t>
    … …  
    10941101   <list style="symbols">
    10951102      <t>
    1096          adding or removing whitespace, where allowed in the header field's syntax
     1103         adding or removing whitespace, where allowed in the header field's
     1104         syntax
    10971105      </t>
    10981106      <t>
    … …  
    11021110      <t>
    11031111         normalizing both header field values in a way that is known to have
    1104          identical semantics, according to the header field's specification (e.g.,
    1105          re-ordering field values when order is not significant;
     1112         identical semantics, according to the header field's specification
     1113         (e.g., re-ordering field values when order is not significant;
    11061114         case-normalization, where values are defined to be case-insensitive)
    11071115      </t>
    … …  
    13721380   <iref item="only-if-cached" primary="true" subitem="Cache Directive" />
    13731381<t>
    1374    The only-if-cached request directive indicates that the client only
    1375    wishes to obtain a stored response. If it receives 3ive, a
    1376    cache &SHOULD; either respond using a stored response that is consistent
    1377    with the other constraints of the request, or respond with a <x:ref>504
    1378    (Gateway Timeout)</x:ref> status code. If a group of caches is being operated as
    1379    a unified system with good internal connectivity, a member cache &MAY;
     1382   The only-if-cached request directive indicates that the client only wishes
     1383   to obtain a stored response. If it receives 3ive, a cache &SHOULD; either
     1384   respond using a stored response that is consistent with the other
     1385   constraints of the request, or respond with a <x:ref>504 (Gateway
     1386   Timeout)</x:ref> status code. If a group of caches is being operated as a
     1387   unified system with good internal connectivity, a member cache &MAY;
    13801388   forward such a request within that group of caches.
    13811389</t>
    … …  
    14331441</t>
    14341442<t>
    1435    &Note; This directive uses the quoted-string form of the argument
    1436    syntax. Senders &SHOULD-NOT; use the token form (even if quoting appears not
    1437    to be needed for single-entry lists).
     1443   &Note; This directive uses the quoted-string form of the argument syntax.
     1444   Senders &SHOULD-NOT; use the token form (even if quoting appears not to be
     1445   needed for single-entry lists).
    14381446</t>
    14391447</section>
    … …  
    14791487</t>
    14801488<t>
    1481    &Note; This directive uses the quoted-string form of the argument
    1482    syntax. Senders &SHOULD-NOT; use the token form (even if quoting appears not
    1483    to be needed for single-entry lists).
     1489   &Note; This directive uses the quoted-string form of the argument syntax.
     1490   Senders &SHOULD-NOT; use the token form (even if quoting appears not to be
     1491   needed for single-entry lists).
    14841492</t>
    14851493</section>
    … …  
    19141922</t>
    19151923<t>
    1916    If an implementation sends a message with one or more Warning header fields to a
    1917    receiver whose version is HTTP/1.0 or lower, then the sender &MUST; include
    1918    in each warning-value a warn-date that matches the <x:ref>Date</x:ref> header
    1919    field in the message.
    1920 </t>
    1921 <t>
    1922    If a system receives a message with a warning-value that includes
    1923    a warn-date, and that warn-date is different from the <x:ref>Date</x:ref>
     1924   If an implementation sends a message with one or more Warning header fields
     1925   to a receiver whose version is HTTP/1.0 or lower, then the sender &MUST;
     1926   include in each warning-value a warn-date that matches the
     1927   <x:ref>Date</x:ref> header field in the message.
     1928</t>
     1929<t>
     1930   If a system receives a message with a warning-value that includes a
     1931   warn-date, and that warn-date is different from the <x:ref>Date</x:ref>
    19241932   value in the response, then that warning-value &MUST; be deleted from the
    1925    message before storing, forwarding, or using it. (preventing the consequences
    1926    of naive caching of Warning header fields.) If all of the warning-values are
    1927    deleted for this reason, the Warning header field &MUST; be deleted as well.
     1933   message before storing, forwarding, or using it. (preventing the
     1934   consequences of naive caching of Warning header fields.) If all of the
     1935   warning-values are deleted for this reason, the Warning header field &MUST;
     1936   be deleted as well.
    19281937</t>
    19291938<t>
Note: See TracChangeset for help on using the changeset viewer.