CODEWITHSUNDEEP
google-chromehttpbrowser-cachecache-control
Brett Janer
Brett Janer

Reputation: 517

Chrome does not invalidate cache when PUT request contains If-Match header

I'm creating a HTTP Web API where some of my resources will be cacheable. A cacheable resource will have two operations, GET & PUT. The GET will return response headers of Cache-Control: public,max-age=3600 & Etag: "2kuSN7rMzfGcB2DKt67EqDWQELA". The PUT will require the If-Match header which will contain the Etag value from a GET of the same resource. My goal is to have the browser cache invalidate a resource when I PUT to that resource. This works fine until I add the If-Match header to the PUT request. When the PUT request contains the If-Match header, subsequent GET requests will fetch from the cache which would be stale data. This is the behavior I've been experiencing with Chrome. Firefox doesn't behave like this, and works as I assume it should. Is this a bug in Chrome or am I misunderstanding some part of the HTTP spec?

Here are some example requests to show behavior:

//correctly fetchs from origin server (returns 200)
GET http://localhost/api/my-number/1
  Response Headers
    cache-control: public,max-age=3600
    etag: "2kuSN7rMzfGcB2DKt67EqDWQELA"
  Response Body
    7

//correctly fetchs from disk cache (returns 200)
GET http://localhost/api/my-number/1
  Response Headers
    cache-control: public,max-age=3600
    etag: "2kuSN7rMzfGcB2DKt67EqDWQELA"
  Response Body
    7

//correctly updates origin server (returns 200)
PUT http://localhost/api/my-number/1
  Request Headers
    if-match: "2kuSN7rMzfGcB2DKt67EqDWQELA"
  Request Body
    8

//incorrectly still fetches from disk cache (returns 200)
GET http://localhost/api/my-number/1
  Response Headers
    cache-control: public,max-age=3600
    etag: "2kuSN7rMzfGcB2DKt67EqDWQELA"
  Response Body
    7

Upvotes: 1

Views: 303

Answers (1)

Kevin Christopher Henry
Kevin Christopher Henry

Reputation: 48952

This is indeed incorrect behavior. RFC 7234 says:

A cache MUST invalidate the effective Request URI... as well as the URI(s) in the Location and Content-Location response header fields (if present) when a non-error status code is received in response to an unsafe request method.

Given that, the bug report you filed looks appropriate to me.

Upvotes: 3

Related Questions