Skip to content

Commit

Permalink
Relax invalidation on Location and Content-Location
Browse files Browse the repository at this point in the history
Fixes #478.
  • Loading branch information
mnot committed Oct 22, 2020
1 parent d290db8 commit 276e286
Showing 1 changed file with 17 additions and 11 deletions.
28 changes: 17 additions & 11 deletions draft-ietf-httpbis-cache-latest.xml
Original file line number Diff line number Diff line change
Expand Up @@ -1135,21 +1135,21 @@
</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
(<xref target="target.resource"/>). This helps prevent denial-of-service attacks.
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 URLs might be discovered
through mechanisms not specified in this document.
</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.
However, a cache &MUST-NOT; trigger an invalidation under these conditions
if the host part of the URI to be invalidated differs from the host part of the target URI
(<xref target="target.resource"/>). This helps prevent denial-of-service attacks.
</t>
<t>
<x:dfn>Invalidate</x:dfn> means that the cache will either remove all
Expand Down Expand Up @@ -2368,6 +2368,11 @@
advisory. In practice, Warning was not added by caches or intermediaries.
(<xref target="field.warning"/>)
</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>
</section>

<section title="Change Log" anchor="change.log" removeInRFC="true">
Expand Down Expand Up @@ -2491,6 +2496,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="invalidation"/>, relax requirements on Content-Location and Location invalidation (<eref target="https://github.com/httpwg/http-core/issues/478"/>)</li>
</ul>
</section>
</section>
Expand Down

0 comments on commit 276e286

Please sign in to comment.