Ignore:
Timestamp:
Jul 29, 2010, 11:11:34 PM (9 years ago)
Author:
fielding@…
Message:

Addresses #109: Clarify entity / representation / variant terminology

Removed entity-header adjective and ABNF and clarified distinction
between payload and representation.

Uncapitalize the phrase effective request URI so that it doesn't
dominate the prose, and define the term "target resource" to be
used instead of the "resource identified by the effective request URI".

File:
1 edited

Legend:

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

    r951 r965  
    504504   unless:
    505505   <list style="symbols">
    506       <t>The presented Effective Request URI (&effective-request-uri;) and
     506      <t>The presented effective request URI (&effective-request-uri;) and
    507507      that of the stored response match, and</t>
    508508      <t>the request method associated with the stored response allows it to
     
    868868   An invalidation based on a URI from a Location or Content-Location header
    869869   &MUST-NOT; be performed if the host part of that URI differs from the host
    870    part in the Effective Request URI (&effective-request-uri;). This helps
     870   part in the effective request URI (&effective-request-uri;). This helps
    871871   prevent denial of service attacks.
    872872</t>
    873873<t>
    874874   A cache that passes through requests for methods it does not understand
    875    &SHOULD; invalidate the Effective Request URI (&effective-request-uri;).
     875   &SHOULD; invalidate the effective request URI (&effective-request-uri;).
    876876</t>
    877877<t>
    878878   Here, "invalidate" means that the cache will either remove all stored
    879    responses related to the Effective Request URI, or will mark these as
     879   responses related to the effective request URI, or will mark these as
    880880   "invalid" and in need of a mandatory validation before they can be returned
    881881   in response to a subsequent request.
     
    10101010   related to caching.
    10111011</t>
    1012 <t>
    1013    For entity-header fields, both sender and recipient refer to either the
    1014    client or the server, depending on who sends and who receives the message.
    1015 </t>
    10161012
    10171013<section anchor="header.age" title="Age">
     
    14351431   <x:anchor-alias value="Expires-v"/>
    14361432<t>
    1437    The "Expires" entity-header field gives the date/time after which the
     1433   The "Expires" header field gives the date/time after which the
    14381434   response is considered stale. See <xref target="expiration.model" /> for
    14391435   further discussion of the freshness model.
     
    26082604  <list style="symbols">
    26092605    <t>
     2606      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/109"/>:
     2607      "Clarify entity / representation / variant terminology"
     2608    </t>
     2609    <t>
    26102610      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>:
    26112611      "consider removing the 'changes from 2068' sections"
Note: See TracChangeset for help on using the changeset viewer.