Merge branch 'master' of github.com:httpwg/http-core

draft-ietf-httpbis-cache-latest.xml

@@ -599,15 +599,17 @@
    responses without a Vary header field), the cache will need to choose one to use.
    When a selecting header field has a known mechanism for doing so (e.g., qvalues on
    <x:ref>Accept</x:ref> and similar request header fields), that mechanism &MAY; be
-   used to select preferred responses; of the remainder, the most recent
+   used to select a preferred response. If such a mechanism is not available, or leads to equally preferred responses, the most recent
    response (as determined by the <x:ref>Date</x:ref> header field) is used, as
    per <xref target="constructing.responses.from.caches"/>.
 </t>
 <t>
-   Note that in practice, some resources might send the Vary header field on
-   responses inconsistently. When a cache has multiple responses for a
-   target URI, and one or more omits the Vary header field, it &SHOULD; use the
-   most recent non-empty value available to select an appropriate response
+   Some resources mistakenly omit the Vary header field from their default
+   response (i.e., the one sent when no more preferable response is available), 
+   selecting it for requests to that resource even when 
+   more preferable responses are available. When a cache has multiple responses for a
+   target URI and one or more omits the Vary header field, it &SHOULD; use the
+   most recent (see <xref target="age.calculations"/>) valid Vary field value available to select an appropriate response
    for the request.
 </t>
 <t>
@@ -1094,13 +1096,40 @@
    response, with the following exceptions:
 </t>
 <ul>
-   <li>The exceptions to header field storage in <xref
-   target="storing.fields"/> also apply to header field updates.</li>
-   <li>Caches &MUST-NOT; update the following header fields:
-   <x:ref>Content-Encoding</x:ref>, <x:ref>Content-Length</x:ref>,
-   Content-MD5 (<xref target="RFC2616" x:fmt="of" x:sec="14.15"/>),
-   <x:ref>Content-Range</x:ref>, <x:ref>ETag</x:ref>.</li>
+   <li>Header fields excepted from storage in <xref target="storing.fields"/>,</li>
+   <li>Header fields that the cache's stored representation of the response depends upon, as described below,</li>
+   <li>Header fields that are automatically processed and removed by the recipient, as described below, and</li>
+   <li>The Content-Length header field.</li>
 </ul>
+<t>
+   In some cases, caches (especially in user agents) store processed
+   representations of the received response, rather than the response itself,
+   and updating header fields that affect that processing can result in
+   inconsistent behavior and security issues. Caches in this situation &MAY;
+   omit these header fields from updating stored representations on an
+   exceptional basis, but &SHOULD; limit such omission to those fields
+   necessary to assure integrity of the stored representation.
+</t>
+<t>
+   For example, a browser might store a response's body after removing
+   content-codings, thereby making its metadata inaccurate. 
+   Updating that stored metadata with a different Content-Encoding
+   header field would be problematic. Likewise, a browser might store a
+   post-parse tree representation of HTML, rather than the body received in
+   the response; updating the Content-Type header field would not be workable
+   in this case, because any assumptions about the format made in parsing would
+   now be invalid.
+</t>
+<t>
+   Furthermore, some fields are automatically processed and removed by the
+   HTTP implementation; for example, the Content-Range header field.
+   Implementations &MAY; automatically omit such header fields from updates,
+   even when the processing does not actually occur.
+</t>
+<t>
+   Note that the Content-* prefix is not a signal that a header field is omitted
+   from update; it is only a convention for naming content-related fields.
+</t>
 </section>
 
 <section title="Freshening Responses with HEAD" anchor="head.effects">
@@ -1149,22 +1178,20 @@
 </t>
 <t>
    A cache &MUST; invalidate the target URI
-   (<xref target="target.resource"/>) and the URI(s) in the
-   <x:ref>Location</x:ref> and <x:ref>Content-Location</x:ref> response header
-   fields (if present) when a non-error status code is received in response to
-   an unsafe request method.
+   (<xref target="target.resource"/>) when a non-error status code is received in response to
+   an unsafe request method (including methods whose safety is unknown).
 </t>
 <t>
-   However, a cache &MUST-NOT; invalidate a URI from a <x:ref>Location</x:ref>
-   or <x:ref>Content-Location</x:ref> response header field if the host part of
-   that URI differs from the host part in the target URI
+   A cache &MAY; invalidate other URIs when a non-error status code is received
+   in response to an unsafe request method (including methods whose safety is unknown).
+   In particular, the URI(s) in the
+   <x:ref>Location</x:ref> and <x:ref>Content-Location</x:ref> response header
+   fields (if present) are candidates for invalidation; other URIs might be discovered
+   through mechanisms not specified in this document.
+   However, a cache &MUST-NOT; trigger an invalidation under these conditions
+   if the origin (<xref target="origin"/>) of the URI to be invalidated differs from that of the target URI
    (<xref target="target.resource"/>). This helps prevent denial-of-service attacks.
 </t>
-<t>
-   A cache &MUST; invalidate the target URI 
-   (<xref target="target.resource"/>) when it receives a non-error response 
-   to a request with a method whose safety is unknown.
-</t>
 <t>
    <x:dfn>Invalidate</x:dfn> means that the cache will either remove all
    stored responses whose target URI matches the given URI, or will mark them
@@ -1922,7 +1949,7 @@
 </section>
 </section>
 
-<section title="Relationship to Applications" anchor="history.lists">
+<section title="Relationship to Applications and Other Caches" anchor="history.lists">
 <t>
    Applications using HTTP often specify additional forms of caching. For
    example, Web browsers often have history mechanisms such as "Back" buttons
@@ -1935,16 +1962,19 @@
 </t>
 <t>
    The requirements in this specification do not necessarily apply to how
-   applications use data after it is retrieved from a HTTP cache. That is, a
+   applications use data after it is retrieved from a HTTP cache. For example, a
    history mechanism can display a previous representation even if it has
    expired, and an application can use cached data in other ways beyond its
    freshness lifetime.
 </t>
 <t>
-   This does not prohibit the application from taking HTTP caching into
+   This specification does not prohibit the application from taking HTTP caching into
    account; for example, a history mechanism might tell the user that a view
    is stale, or it might honor cache directives (e.g., Cache-Control:
-   no-store).
+   no-store). In particular, when an application caches data and does not make this
+   apparent to or easily controllable by the user, it is strongly encouraged to
+   honour basic control mechanisms like Cache-Control: no-store, as they
+   indicate the resource's intent regarding caching.
 </t>
 </section>
 
@@ -2150,6 +2180,7 @@
       <x:has anchor="field-values"/>
       <x:has anchor="message.transformations"/>
       <x:has anchor="messages"/>
+      <x:has anchor="origin"/>
       <x:has anchor="overview.of.status.codes"/>
       <x:has anchor="precedence"/>
       <x:has anchor="preconditions"/>
@@ -2368,14 +2399,24 @@
 <?ENDINC build/draft-ietf-httpbis-cache-latest.abnf-appendix ?>
 
 <section title="Changes from RFC 7234" anchor="changes.from.rfc.7234">
-<t>
-   Handling invalid and multiple Age header field values has been clarified.
-   (<xref target="field.age"/>)
-</t>
 <t>
    Handling of duplicate and conflicting cache directives has been clarified.
    (<xref target="calculating.freshness.lifetime"/>)
 </t>
+<t>
+   Cache invalidation of the URIs in the Location and Content-Location
+   header fields is no longer required, but still allowed.
+   (<xref target="invalidation"/>)
+</t>
+<t>
+   Cache invalidation of the URIs in the Location and Content-Location header fields is disallowed
+   when the origin is different; previously, it was the host.
+   (<xref target="invalidation"/>)
+</t>
+<t>
+   Handling invalid and multiple Age header field values has been clarified.
+   (<xref target="field.age"/>)
+</t>
 <t>
    Some cache directives defined by this specification now have stronger
    prohibitions against generating the quoted form of their values, since
@@ -2527,13 +2568,16 @@
 <ul x:when-empty="None yet.">
   <li>In <xref target="serving.stale.responses"/>, remove 'no-store', as it won't be in cache in the first place (<eref target="https://github.com/httpwg/http-core/issues/447"/>)</li>
   <li>In <xref target="storing.fields"/>, make it clear that only response headers need be stored (<eref target="https://github.com/httpwg/http-core/issues/457"/>)</li>
-  <li>In <xref target="validation.response"/>, mention retry of failed validation requests (<eref target="https://github.com/httpwg/http-core/issues/462"/>)</li>
   <li>In <xref target="calculating.freshness.lifetime"/> clarify how to handle invalid and conflicting directives (<eref target="https://github.com/httpwg/http-core/issues/460"/>)</li>
+  <li>In <xref target="validation.response"/>, mention retry of failed validation requests (<eref target="https://github.com/httpwg/http-core/issues/462"/>)</li>
   <li>In <xref target="validation.response"/>, clarify requirement on storing a full response to a conditional request (<eref target="https://github.com/httpwg/http-core/issues/463"/>)</li>
   <li>In <xref target="field.age"/>, clarify error handling (<eref target="https://github.com/httpwg/http-core/issues/471"/>)</li>
   <li>In <xref target="expiration.model"/>, remove spurious "UTC" (<eref target="https://github.com/httpwg/http-core/issues/472"/>)</li>
   <li>In <xref target="expiration.model"/>, correct the date-related rule names to consider case-insensitive (<eref target="https://github.com/httpwg/http-core/issues/473"/>)</li>
+  <li>In <xref target="history.lists"/>, strengthen recommendation for application caches to pay attention to cache directives (<eref target="https://github.com/httpwg/http-core/issues/474"/>)</li>
   <li>In <xref target="constructing.responses.from.caches"/>, mention collapsed requests (<eref target="https://github.com/httpwg/http-core/issues/475"/>)</li>
+  <li>In <xref target="invalidation"/>, relax requirements on Content-Location and Location invalidation (<eref target="https://github.com/httpwg/http-core/issues/478"/>)</li>
+  <li>In <xref target="freshening.responses"/>, refine the exceptions to update on a 304 (<eref target="https://github.com/httpwg/http-core/issues/488"/>)</li>
 </ul>
 </section>
 </section>