Ignore:
Timestamp:
06/01/13 09:44:29 (8 years ago)
Author:
fielding@…
Message:

(editorial) more consistency regarding xrefs to caching header fields

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2091 r2092  
    325325  <c>Content-Language</c> <c><xref target="header.content-language"/></c>
    326326  <c>Content-Location</c> <c><xref target="header.content-location"/></c>
    327   <c>Expires</c> <c>&header-expires;</c>
    328327</texttable>
    329328
     
    12651264</t>
    12661265<t>
     1266   The response to a GET request is cacheable; a cache &MAY; use it to satisfy
     1267   subsequent GET and HEAD requests unless otherwise indicated by the
     1268   Cache-Control header field (&header-cache-control;).
     1269</t>
     1270<t>
    12671271   A payload within a GET request message has no defined semantics;
    12681272   sending a payload body on a GET request might cause some existing
    12691273   implementations to reject the request.
    1270 </t>
    1271 <t>
    1272    The response to a GET request is cacheable and &MAY; be used to satisfy
    1273    subsequent GET and HEAD requests (see &caching;).
    12741274</t>
    12751275</section>
     
    12841284   The HEAD method is identical to GET except that the server &MUST-NOT;
    12851285   send a message body in the response (i.e., the response terminates at the
    1286    end of the header block). The metadata contained in the HTTP header fields
    1287    in response to a HEAD request &SHOULD; be identical to the information sent
    1288    in response to a GET request. This method can be used for obtaining
    1289    metadata about the selected representation without transferring the
    1290    representation data. This method is often used for testing hypertext links
    1291    for validity, accessibility, and recent modification.
    1292 </t>
    1293 <t>
    1294    The response to a HEAD request is cacheable and &MAY; be used to satisfy
    1295    a subsequent HEAD request. It also has potential side effects on
    1296    previously stored responses to GET; see &p6-head;.
     1286   end of the header block). Aside from the payload header fields
     1287   (<xref target="payload"/>), the server &SHOULD; send the same header fields
     1288   in response to a HEAD request as it would have sent if the request had been
     1289   a GET. This method can be used for obtaining metadata about the selected
     1290   representation without transferring the representation data. This method is
     1291   often used for testing hypertext links for validity, accessibility, and
     1292   recent modification.
     1293</t>
     1294<t>
     1295   The response to a HEAD request is cacheable; a cache &MAY; use it to
     1296   satisfy subsequent HEAD requests unless otherwise indicated by the
     1297   Cache-Control header field (&header-cache-control;). A HEAD response might
     1298   also have an effect on previously cached responses to GET; see &p6-head;.
    12971299</t>
    12981300<t>
     
    17341736  <ttcol>Defined in...</ttcol>
    17351737
     1738  <c>Cache-Control</c> <c>&header-cache-control;</c>
     1739  <c>Expect</c> <c><xref target="header.expect"/></c>
    17361740  <c>Host</c> <c>&header-host;</c>
    17371741  <c>Max-Forwards</c> <c><xref target="header.max-forwards"/></c>
    1738   <c>Expect</c> <c><xref target="header.expect"/></c>
     1742  <c>Pragma</c> <c>&header-pragma;</c>
    17391743  <c>Range</c> <c>&header-range;</c>
     1744  <c>TE</c> <c>&header-te;</c>
    17401745</texttable>
    1741 
    1742 <section title="Max-Forwards" anchor="header.max-forwards">
    1743   <iref primary="true" item="Max-Forwards header field" x:for-anchor=""/>
    1744   <x:anchor-alias value="Max-Forwards"/>
    1745 <t>
    1746    The "Max-Forwards" header field provides a mechanism with the
    1747    TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>)
    1748    methods to limit the number of times that the request is forwarded by
    1749    proxies. This can be useful when the client is attempting to
    1750    trace a request that appears to be failing or looping mid-chain.
    1751 </t>
    1752 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Max-Forwards"/>
    1753   <x:ref>Max-Forwards</x:ref> = 1*<x:ref>DIGIT</x:ref>
    1754 </artwork></figure>
    1755 <t>
    1756    The Max-Forwards value is a decimal integer indicating the remaining
    1757    number of times this request message can be forwarded.
    1758 </t>
    1759 <t>
    1760    Each recipient of a TRACE or OPTIONS request
    1761    containing a Max-Forwards header field &MUST; check and update its
    1762    value prior to forwarding the request. If the received value is zero
    1763    (0), the recipient &MUST-NOT; forward the request; instead, it &MUST;
    1764    respond as the final recipient. If the received Max-Forwards value is
    1765    greater than zero, then the forwarded message &MUST; contain an updated
    1766    Max-Forwards field with a value decremented by one (1).
    1767 </t>
    1768 <t>
    1769    The Max-Forwards header field &MAY; be ignored for all other request
    1770    methods.
    1771 </t>
    1772 </section>
    17731746
    17741747<section title="Expect" anchor="header.expect">
     
    19431916</section>
    19441917</section>
     1918
     1919<section title="Max-Forwards" anchor="header.max-forwards">
     1920  <iref primary="true" item="Max-Forwards header field" x:for-anchor=""/>
     1921  <x:anchor-alias value="Max-Forwards"/>
     1922<t>
     1923   The "Max-Forwards" header field provides a mechanism with the
     1924   TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>)
     1925   methods to limit the number of times that the request is forwarded by
     1926   proxies. This can be useful when the client is attempting to
     1927   trace a request that appears to be failing or looping mid-chain.
     1928</t>
     1929<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Max-Forwards"/>
     1930  <x:ref>Max-Forwards</x:ref> = 1*<x:ref>DIGIT</x:ref>
     1931</artwork></figure>
     1932<t>
     1933   The Max-Forwards value is a decimal integer indicating the remaining
     1934   number of times this request message can be forwarded.
     1935</t>
     1936<t>
     1937   Each recipient of a TRACE or OPTIONS request
     1938   containing a Max-Forwards header field &MUST; check and update its
     1939   value prior to forwarding the request. If the received value is zero
     1940   (0), the recipient &MUST-NOT; forward the request; instead, it &MUST;
     1941   respond as the final recipient. If the received Max-Forwards value is
     1942   greater than zero, then the forwarded message &MUST; contain an updated
     1943   Max-Forwards field with a value decremented by one (1).
     1944</t>
     1945<t>
     1946   The Max-Forwards header field &MAY; be ignored for all other request
     1947   methods.
     1948</t>
     1949</section>
    19451950</section>
    19461951
     
    23352340  <c>From</c> <c><xref target="header.from"/></c>
    23362341  <c>Referer</c> <c><xref target="header.referer"/></c>
    2337   <c>TE</c> <c>&header-te;</c>
    23382342  <c>User-Agent</c> <c><xref target="header.user-agent"/></c>
    23392343</texttable>
     
    35023506<t>
    35033507   Response header fields can supply control data that supplements the
    3504    status code or instructs the client where to go next.
     3508   status code, directs caching, or instructs the client where to go next.
    35053509</t>
    35063510<texttable align="left">
     
    35083512
    35093513  <c>Age</c> <c>&header-age;</c>
     3514  <c>Cache-Control</c> <c>&header-cache-control;</c>
     3515  <c>Expires</c> <c>&header-expires;</c>
    35103516  <c>Date</c> <c><xref target="header.date"/></c>
    35113517  <c>Location</c> <c><xref target="header.location"/></c>
    35123518  <c>Retry-After</c> <c><xref target="header.retry-after"/></c>
     3519  <c>Warning</c> <c>&header-warning;</c>
    35133520</texttable>
    35143521
     
    38823889   header fields are not limited to those defined by this specification.
    38833890</t>
     3891<figure><preamble>For example, a response that contains</preamble><artwork type="example">
     3892  Vary: accept-encoding, accept-language
     3893</artwork><postamble>indicates that the origin server might have used the
     3894   request's <x:ref>Accept-Encoding</x:ref> and <x:ref>Accept-Language</x:ref>
     3895   fields (or lack thereof) as determining factors while choosing this
     3896   <x:ref>selected representation</x:ref>.
     3897</postamble></figure>
    38843898<t>
    38853899   An origin server might send Vary with a list of fields for two purposes:
     
    39063920</t>
    39073921<t>
    3908    Unless it has been deliberately configured to prevent cache transparency,
    3909    an origin server &SHOULD; send a Vary header field in a cacheable
    3910    response that is subject to proactive negotiation.
    3911 </t>
    3912 <figure><preamble>For example, a response that contains</preamble><artwork type="example">
    3913   Vary: accept-encoding, accept-language
    3914 </artwork><postamble>indicates that the origin server might have used the
    3915    request's <x:ref>Accept-Encoding</x:ref> and <x:ref>Accept-Language</x:ref>
    3916    fields (or lack thereof) as determining factors while choosing this
    3917    <x:ref>selected representation</x:ref>.</postamble></figure>
     3922   An origin server &SHOULD; send a Vary header field when its algorithm for
     3923   selecting a representation varies based on aspects of the request message
     3924   other than the method and request target, unless the variance cannot be
     3925   crossed or the origin server has been deliberately configured to prevent
     3926   cache transparency. For example, there is no need to send the
     3927   Authorization field name (&header-authorization;) in Vary because
     3928   reuse across users is constrained by the field definition. Likewise,
     3929   Cache-Control directives (&header-cache-control;) might be used to supplant
     3930   the need for Vary, particularly when the variance is considered less
     3931   significant than the performance cost of Vary's impact on caching.
     3932</t>
    39183933</section>
    39193934</section>
Note: See TracChangeset for help on using the changeset viewer.