Ignore:
Timestamp:
Sep 7, 2010, 4:46:12 AM (9 years ago)
Author:
julian.reschke@…
Message:

Uniform use of 'header field' (see #234)

File:
1 edited

Legend:

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

    r981 r994  
    439439      <t>the "no-store" cache directive (see <xref
    440440      target="header.cache-control" />) does not appear in request or response
    441       headers, and</t>
     441      header fields, and</t>
    442442      <t>the "private" cache response directive (see <xref
    443443      target="cache-response-directive" /> does not appear in the response, if
    444444      the cache is shared, and</t>
    445       <t>the "Authorization" header (see &header-authorization;) does not
     445      <t>the "Authorization" header field (see &header-authorization;) does not
    446446      appear in the request, if the cache is shared, unless the response
    447447      explicitly allows it (see <xref target="caching.authenticated.responses"
     
    449449      <t>the response either:
    450450         <list style="symbols">
    451             <t>contains an Expires header (see <xref target="header.expires"
     451            <t>contains an Expires header field (see <xref target="header.expires"
    452452            />), or</t>
    453453            <t>contains a max-age response cache directive (see <xref
     
    482482<t>
    483483   A cache that receives an incomplete response (for example, with fewer bytes
    484    of data than specified in a Content-Length header) can store the response,
     484   of data than specified in a Content-Length header field) can store the response,
    485485   but &MUST; treat it as a partial response &partial;. Partial responses can
    486486   be combined as described in &combining-byte-ranges;; the result might be a
     
    490490</t>
    491491<t>
    492    A cache that does not support the Range and Content-Range headers
     492   A cache that does not support the Range and Content-Range header fields
    493493   &MUST-NOT; store incomplete or partial responses.
    494494</t>
     
    508508      <t>the request method associated with the stored response allows it to
    509509      be used for the presented request, and</t>
    510       <t>selecting request-headers nominated by the stored response (if any)
     510      <t>selecting request-header fields nominated by the stored response (if any)
    511511      match those presented (see <xref target="caching.negotiated.responses"
    512512      />), and</t>
     
    543543<t>
    544544   Caches &MUST; use the most recent response (as determined by the Date
    545    header) when more than one suitable response is stored. They can also
     545   header field) when more than one suitable response is stored. They can also
    546546   forward a request with "Cache-Control: max-age=0" or "Cache-Control:
    547547   no-cache" to disambiguate which response to use.
     
    558558   The primary mechanism for determining freshness is for an origin server to
    559559   provide an explicit expiration time in the future, using either the Expires
    560    header (<xref target="header.expires" />) or the max-age response cache
     560   header field (<xref target="header.expires" />) or the max-age response cache
    561561   directive (<xref target="cache-response-directive" />). Generally, origin
    562562   servers will assign future explicit expiration times to responses in the
     
    573573   Since origin servers do not always provide explicit expiration times, HTTP
    574574   caches &MAY; assign heuristic expiration times when explicit times are not
    575    specified, employing algorithms that use other header values (such as the
     575   specified, employing algorithms that use other heade field values (such as the
    576576   Last-Modified time) to estimate a plausible expiration time. The HTTP/1.1
    577577   specification does not provide specific algorithms, but does impose
     
    619619      <t>If the max-age response cache directive (<xref
    620620      target="cache-response-directive" />) is present, use its value, or</t>
    621       <t>If the Expires response header (<xref target="header.expires" />) is
    622       present, use its value minus the value of the Date response header,
     621      <t>If the Expires response header field (<xref target="header.expires" />) is
     622      present, use its value minus the value of the Date response header field,
    623623      or</t>
    624624      <t>Otherwise, no explicit expiration time is present in the response. A
     
    643643<t>
    644644   When a heuristic is used to calculate freshness lifetime, the cache
    645    &SHOULD; attach a Warning header with a 113 warn-code to the response if
     645   &SHOULD; attach a Warning header field with a 113 warn-code to the response if
    646646   its current_age is more than 24 hours and such a warning is not already
    647647   present.
    648648</t>
    649649<t>
    650    Also, if the response has a Last-Modified header (&header-last-modified;),
     650   Also, if the response has a Last-Modified header field (&header-last-modified;),
    651651   the heuristic expiration value &SHOULD; be no more than some fraction of
    652652   the interval since that time. A typical setting of this fraction might be
     
    668668<section anchor="age.calculations" title="Calculating Age">
    669669<t>
    670    HTTP/1.1 uses the Age response-header to convey the estimated age of the
     670   HTTP/1.1 uses the Age response-header field to convey the estimated age of the
    671671   response message when obtained from a cache. The Age field value is the
    672672   cache's estimate of the amount of time since the response was generated or
     
    683683   <list>
    684684      <t>
    685          The term "age_value" denotes the value of the Age header (<xref
     685         The term "age_value" denotes the value of the Age header field (<xref
    686686         target="header.age"/>), in a form appropriate for arithmetic
    687687         operation; or 0, if not available.
     
    693693   <list>
    694694      <t>
    695          HTTP/1.1 requires origin servers to send a Date header, if possible,
     695         HTTP/1.1 requires origin servers to send a Date header field, if possible,
    696696         with every response, giving the time at which the response was
    697697         generated. The term "date_value" denotes the value of the Date
    698          header, in a form appropriate for arithmetic operations. See
    699          &header-date; for the definition of the Date header, and for
    700          requirements regarding responses without a Date response header.
     698         header field, in a form appropriate for arithmetic operations. See
     699         &header-date; for the definition of the Date header field, and for
     700         requirements regarding responses without it.
    701701      </t>
    702702   </list>
     
    788788</t>
    789789<t>
    790    Stale responses &SHOULD; have a Warning header with the 110 warn-code (see
     790   Stale responses &SHOULD; have a Warning header field with the 110 warn-code (see
    791791   <xref target="header.warning" />). Likewise, the 112 warn-code &SHOULD; be
    792792   sent on stale responses if the cache is disconnected.
     
    797797   requesting client, and the received response is no longer fresh, the cache
    798798   &SHOULD; forward it to the requesting client without adding a new Warning
    799    (but without removing any existing Warning headers). A cache &SHOULD-NOT;
     799   (but without removing any existing Warning header fields). A cache &SHOULD-NOT;
    800800   attempt to validate a response simply because that response became stale in
    801801   transit.
     
    816816<t>
    817817   When sending such a conditional request, the cache &SHOULD; add an
    818    If-Modified-Since header whose value is that of the Last-Modified header
    819    from the selected (see <xref target="caching.negotiated.responses"/>)
     818   If-Modified-Since header field whose value is that of the Last-Modified header
     819   field from the selected (see <xref target="caching.negotiated.responses"/>)
    820820   stored response, if available.
    821821</t>
    822822<t>
    823    Additionally, the cache &SHOULD; add an If-None-Match header whose value is
    824    that of the ETag header(s) from all responses stored for the requested URI,
     823   Additionally, the cache &SHOULD; add an If-None-Match header field whose value is
     824   that of the ETag header field(s) from all responses stored for the requested URI,
    825825   if present. However, if any of the stored responses contains only partial
    826826   content, its entity-tag &SHOULD-NOT; be included in the If-None-Match
     
    830830<t>
    831831   A 304 (Not Modified) response status code indicates that the stored
    832    response can be updated and reused; see <xref target="combining.headers"/>.
     832   response can be updated and reused; see <xref target="combining.responses"/>.
    833833</t>
    834834<t>
     
    856856   The following HTTP methods &MUST; cause a cache to invalidate the effective
    857857   Request URI (&effective-request-uri;) as well as the URI(s) in the Location
    858    and Content-Location headers (if present):
     858   and Content-Location header fields (if present):
    859859   <list style="symbols">
    860860      <t>PUT</t>
     
    864864</t>
    865865<t>
    866    An invalidation based on a URI from a Location or Content-Location header
     866   An invalidation based on a URI from a Location or Content-Location header field
    867867   &MUST-NOT; be performed if the host part of that URI differs from the host
    868868   part in the effective request URI (&effective-request-uri;). This helps
     
    891891<t>
    892892   Shared caches &MUST-NOT; use a cached response to a request with an
    893    Authorization header (&header-authorization;) to satisfy any subsequent
     893   Authorization header field (&header-authorization;) to satisfy any subsequent
    894894   request unless a cache directive that allows such responses to be stored is
    895895   present in the response.
     
    917917   When a cache receives a request that can be satisfied by a stored response
    918918   that has a Vary header field (<xref target="header.vary"/>), it &MUST-NOT;
    919    use that response unless all of the selecting request-headers nominated by
    920    the Vary header match in both the original request (i.e., that associated
     919   use that response unless all of the selecting request-header fields nominated by
     920   the Vary header field match in both the original request (i.e., that associated
    921921   with the stored response), and the presented request.
    922922</t>
    923923<t>
    924    The selecting request-headers from two requests are defined to match if and
     924   The selecting request-header fields from two requests are defined to match if and
    925925   only if those in the first request can be transformed to those in the
    926926   second request by applying any of the following:
    927927   <list style="symbols">
    928928      <t>
    929          adding or removing whitespace, where allowed in the header's syntax
     929         adding or removing whitespace, where allowed in the header field's syntax
    930930      </t>
    931931      <t>
     
    934934      </t>
    935935      <t>
    936          normalizing both header values in a way that is known to have
    937          identical semantics, according to the header's specification (e.g.,
     936         normalizing both header field values in a way that is known to have
     937         identical semantics, according to the header field's specification (e.g.,
    938938         re-ordering field values when order is not significant;
    939939         case-normalization, where values are defined to be case-insensitive)
     
    952952</t>
    953953<t>
    954    The stored response with matching selecting request-headers is known as the
     954   The stored response with matching selecting request-header fields is known as the
    955955   selected response.
    956956</t>
     
    962962</section>
    963963
    964 <section anchor="combining.headers" title="Combining Responses">
     964<section anchor="combining.responses" title="Combining Responses">
    965965<t>
    966966   When a cache receives a 304 (Not Modified) response or a 206 (Partial
     
    984984</t>
    985985<t>
    986    The stored response headers are used as those of the updated response,
     986   The stored response header fields are used as those of the updated response,
    987987   except that
    988988   <list style="symbols">
    989       <t>any stored Warning headers with warn-code 1xx (see <xref
     989      <t>any stored Warning header fields with warn-code 1xx (see <xref
    990990      target="header.warning" />) &MUST; be deleted.</t>
    991       <t>any stored Warning headers with warn-code 2xx &MUST; be retained.</t>
    992       <t>any other headers provided in the new response &MUST; replace all
    993       instances of the corresponding headers from the stored response.</t>
    994    </list>
    995 </t>
    996 <t>
    997    The updated response headers &MUST; be used to replace those of the stored
     991      <t>any stored Warning header fields with warn-code 2xx &MUST; be retained.</t>
     992      <t>any other header fields provided in the new response &MUST; replace all
     993      instances of the corresponding header fields from the stored response.</t>
     994   </list>
     995</t>
     996<t>
     997   The updated response header fields &MUST; be used to replace those of the stored
    998998   response in cache (unless the stored response is removed from cache). In
    999999   the case of a 206 response, the combined representation &MAY; be stored.
     
    10351035   If a cache receives a value larger than the largest positive integer it can
    10361036   represent, or if any of its age calculations overflows, it &MUST; transmit
    1037    an Age header with a field-value of 2147483648 (2<x:sup>31</x:sup>). Caches
     1037   an Age header field with a field-value of 2147483648 (2<x:sup>31</x:sup>). Caches
    10381038   &SHOULD; use an arithmetic type of at least 31 bits of range.
    10391039</t>
     
    11791179      <t>The no-transform request directive indicates that an intermediate
    11801180      cache or proxy &MUST-NOT; change the Content-Encoding, Content-Range or
    1181       Content-Type request headers, nor the request representation.</t>
     1181      Content-Type request header fields, nor the request representation.</t>
    11821182   </list>
    11831183</t>
     
    12381238      <t>If the private response directive specifies one or more field-names,
    12391239      this requirement is limited to the field-values associated with the
    1240       listed response headers. That is, the specified field-names(s)
     1240      listed response header fields. That is, the specified field-names(s)
    12411241      &MUST-NOT; be stored by a shared cache, whereas the remainder of the
    12421242      response message &MAY; be.</t>
     
    12611261      <t>If the no-cache response directive specifies one or more field-names,
    12621262      this requirement is limited to the field-values associated with the
    1263       listed response headers. That is, the specified field-name(s) &MUST-NOT;
     1263      listed response header fields. That is, the specified field-name(s) &MUST-NOT;
    12641264      be sent in the response to a subsequent request without successful
    12651265      validation on the origin server. This allows an origin server to prevent
     
    13371337      <t>The s-maxage response directive indicates that, in shared caches, the
    13381338      maximum age specified by this directive overrides the maximum age
    1339       specified by either the max-age directive or the Expires header. The
     1339      specified by either the max-age directive or the Expires header field. The
    13401340      s-maxage directive also implies the semantics of the proxy-revalidate
    13411341      response directive.</t>
     
    13491349      <t>The no-transform response directive indicates that an intermediate
    13501350      cache or proxy &MUST-NOT; change the Content-Encoding, Content-Range or
    1351       Content-Type response headers, nor the response representation.</t>
     1351      Content-Type response header fields, nor the response representation.</t>
    13521352   </list>
    13531353</t>
     
    15401540<t>
    15411541   The set of header fields named by the Vary field value is known as the
    1542    selecting request-headers.
     1542   selecting request-header fields.
    15431543</t>
    15441544<t>
     
    15541554<t>
    15551555   A Vary field value of "*" signals that unspecified parameters not limited
    1556    to the request-headers (e.g., the network address of the client), play a
     1556   to the request-header fields (e.g., the network address of the client), play a
    15571557   role in the selection of the response representation; therefore, a cache
    15581558   cannot determine whether this response is appropriate. The "*" value
     
    15881588</t>
    15891589<t>
    1590    Warning headers can in general be applied to any message, however some
     1590   Warning header fields can in general be applied to any message, however some
    15911591   warn-codes are specific to caches and can only be applied to response
    15921592   messages.
     
    16021602  <x:ref>warn-agent</x:ref> = ( <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ) / <x:ref>pseudonym</x:ref>
    16031603                  ; the name or pseudonym of the server adding
    1604                   ; the Warning header, for use in debugging
     1604                  ; the Warning header field, for use in debugging
    16051605  <x:ref>warn-text</x:ref>  = <x:ref>quoted-string</x:ref>
    16061606  <x:ref>warn-date</x:ref>  = <x:ref>DQUOTE</x:ref> <x:ref>HTTP-date</x:ref> <x:ref>DQUOTE</x:ref>
     
    16161616</t>
    16171617<t>
    1618    Systems that generate multiple Warning headers &SHOULD; order them with
    1619    this user agent behavior in mind. New Warning headers &SHOULD; be added
    1620    after any existing Warning headers.
     1618   Systems that generate multiple Warning header fields &SHOULD; order them with
     1619   this user agent behavior in mind. New Warning header fields &SHOULD; be added
     1620   after any existing Warning headers fields.
    16211621</t>
    16221622<t>
     
    16361636</t>
    16371637<t>
    1638    If an implementation sends a message with one or more Warning headers to a
     1638   If an implementation sends a message with one or more Warning header fields to a
    16391639   receiver whose version is HTTP/1.0 or lower, then the sender &MUST; include
    1640    in each warning-value a warn-date that matches the Date header in the
     1640   in each warning-value a warn-date that matches the Date header field in the
    16411641   message.
    16421642</t>
     
    16471647   storing, forwarding, or using it. (preventing the consequences of naive
    16481648   caching of Warning header fields.) If all of the warning-values are deleted
    1649    for this reason, the Warning header &MUST; be deleted as well.
     1649   for this reason, the Warning header field &MUST; be deleted as well.
    16501650</t>
    16511651<t>
     
    22742274</t>
    22752275<t>
    2276   Do not mention RFC 2047 encoding and multiple languages in Warning headers
     2276  Do not mention RFC 2047 encoding and multiple languages in Warning header fields
    22772277  anymore, as these aspects never were implemented.
    22782278  (<xref target="header.warning" />)
     
    24172417<section anchor="changes.since.02" title="Since draft-ietf-httpbis-p6-cache-02">
    24182418<t>
    2419   Ongoing work on IANA Message Header Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40" />):
     2419  Ongoing work on IANA Message Header Field Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40" />):
    24202420  <list style="symbols">
    2421     <t>Reference RFC 3984, and update header registrations for headers defined in this
     2421    <t>Reference RFC 3984, and update header field registrations for header fields defined in this
    24222422      document.</t>
    24232423  </list>
     
    24482448    <t>
    24492449      Rewrite ABNFs to spell out whitespace rules, factor out
    2450       header value format definitions.
     2450      header field value format definitions.
    24512451    </t>
    24522452  </list>
     
    24962496    <t>
    24972497      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/37"/>:
    2498       Vary and non-existant headers
     2498      WVary and non-existant headers"
    24992499    </t>
    25002500  </list>
Note: See TracChangeset for help on using the changeset viewer.