How do I invalidate HTTP cache with the Location header?

Question

On cache invalidation, the HTTP spec says:

Some HTTP methods MUST cause a cache to invalidate an entity. This is either the entity referred to by the Request-URI, or by the Location or Content-Location headers (if present).

I am trying to invalidate an entry in my cache through the use of the Location header, but it doesn't appear to be working. Here's my use case:

1. 15:13:23.9988 | GET | folders/folder.34/contents - 200 (OK)
2. 15:13:24.1318 | PUT | folders/folder.34/contents/test.docx - 201 (Created)
3. 15:13:24.1548 | GET | folders/folder.34/contents - 200 (OK) (cached)

The response of (2) contains a Location header with the URI used in requests (1) and (3). I believe this should invalidate the cached entry for folders/folder.34/contents, but the response in (3) appears to be coming from cache anyway according to the HttpWebResponse.IsFromCache property.

I have tried numerous URI formats in the Location header, including:

• Location: ../../../folders/folder.34/contents (and other assorted '../' counts)
• Location: folders/folder.34/contents
• Location: /folders/folder.34/contents
• Location: http://myhostname/folders/folder.34/contents

But still (3) always seems to come from cache. What am I doing wrong here?

Answer 1

HTTPBis is much clearer:

https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-p6-cache-22#section-6

Because unsafe request methods (Section 4.2.1 of [Part2]) such as
PUT, POST or DELETE have the potential for changing state on the
origin server, intervening caches can use them to keep their contents
up-to-date.

A cache MUST invalidate the effective Request URI (Section 5.5 of
[Part1]) as well as the URI(s) in the Location and Content-Location
response header fields (if present) when a non-error response to a
request with an unsafe method is received.

So if this is not the behavior you're seeing, my assumption would simply be that the particular HTTP client you are using does not have the correct behavior.

I'd especially expect:

Location: /folders/folder.34/contents

To have the correct behavior.