Refine how headers are excepted from update on 304

draft-ietf-httpbis-cache-latest.xml

@@ -1094,13 +1094,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">
@@ -2533,6 +2560,7 @@
   <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="freshening.responses"/>, refine the exceptions to update on a 304 (<eref target="https://github.com/httpwg/http-core/issues/488"/>)</li>
   <li>In <xref target="constructing.responses.from.caches"/>, mention collapsed requests (<eref target="https://github.com/httpwg/http-core/issues/475"/>)</li>
 </ul>
 </section>