Refine how headers are excepted from update on 304

Fixes #488.

draft-ietf-httpbis-cache-latest.xml

@@ -1080,13 +1080,38 @@
    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 behaviour 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 cache might store a response after removing
+   content-codings; updating that response with a different Content-Encoding
+   header field would be problematic. Likewise, a browser cache might store a
+   post-parse tree representation of HTML, rather than the bytes received in
+   the response; updating the Content-Type header field would not be workable
+   in this case.
+</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">
@@ -2491,6 +2516,7 @@
 <section title="Since draft-ietf-httpbis-cache-12" anchor="changes.since.12">
 <ul x:when-empty="None yet.">
    <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="freshening.responses"/>, refine the exceptions to update on a 304 (<eref target="https://github.com/httpwg/http-core/issues/488"/>)</li>
 </ul>
 </section>
 </section>