2

We're designing a REST service with server-side caching. We'd like to provide an option to the client to specifically ask for latest data even if the cached data has not expired. I'm looking into the HTTP 1.1 spec to see if there exists a standard way to do this, and the Cache Revalidation and Reload Controls appears to fit my need.

Questions:

  • Should we just use Cache Revalidation and Reload Controls?
  • If not, is it acceptable to include an If-Modified-Since header with epoch time, causing the server to always consider the resource as have changed? The spec doesn't preclude this, but I'm wondering if I'm abusing :) the intent of the header?
  • What'd be a good way to identify the resource to refresh? In our case, the URL path alone is not enough, and I'm not sure if query or matrix parameters are considered as part of a unique URL. What about using an ETag?
Abhijit Sarkar
  • 21,927
  • 20
  • 110
  • 219

2 Answers2

2

If your client wants a completely fresh representation of a resource, it may specify max-age=0 to do that. That is actually the intent to receive a response no older than 0 seconds.

All other mechanisms you mentioned (If-Modified-Since, ETag, If-Match, etc.) are all working with caches to make sure the resource is in some state. They work only, if you definitely know you have a valid state of the resource. You can think of it as optimistic locking. You can make conditional requests for when the resource did, or did not change. However you have to know whether you are expecting a change or not.

You could potentially misuse the If-Modified-Since as you say, but max-age communicates your intent better.

Also note, by design there may be multiple caches along the way, not just your server side cache. Most often the client caches also, and there may be other transparent caches on the way.

Robert Bräutigam
  • 7,514
  • 1
  • 20
  • 38
  • 1
    What about `Cache-Control: no-cache`? Acc. to the spec and [this thread](http://stackoverflow.com/questions/1046966/whats-the-difference-between-cache-control-max-age-0-and-no-cache), that seems to be more appropriate, no? – Abhijit Sarkar Feb 08 '16 at 07:30
  • 1
    Depends of course. There is a subtle difference, which may or may not be of importance. With `no-cache` you say that you do not want the response to be cached at all, it must be revalidated again next time. With `max-age=0` you just say you want a current representation now, but it may be cached normally afterwards. Technically I should have said `max-age=0, must-revalidate`, that is binding to all caches even if configured otherwise. – Robert Bräutigam Feb 08 '16 at 07:54
  • 1
    Thank you. Can you point me to the portion of the spec that states this difference so that I can use that as a reference? – Abhijit Sarkar Feb 08 '16 at 07:56
  • 1
    Sure, the descriptions for no-cache, max-age, and must-revalidate are here: https://tools.ietf.org/html/rfc7234#section-5.2.2 – Robert Bräutigam Feb 08 '16 at 08:05
  • 1
    After reading [section-5.2.1.4](https://tools.ietf.org/html/rfc7234#section-5.2.1.4), it appears that `no-cache` **request directive** best fits my need. Quoting -"The "no-cache" request directive indicates that a cache MUST NOT use a stored response to satisfy the request without successful validation on the origin server." Nothing is said about subsequent requests, which is exactly what I want. There is also a `no-cache` response directive in [section-5.2.2.2](https://tools.ietf.org/html/rfc7234#section-5.2.2.2), which agrees with what you said but also applies to subsequent requests. – Abhijit Sarkar Feb 08 '16 at 08:38
  • 1
    You are right, my mistake! Linked and quoted the wrong chapter. – Robert Bräutigam Feb 08 '16 at 08:45
1

According to section-5.2.1.4, it appears that no-cache request directive best fits my need.

The "no-cache" request directive indicates that a cache MUST NOT use a stored response to satisfy the request without successful validation on the origin server.

Nothing is said about subsequent requests, which is exactly what I want. There is also a no-cache response directive in section-5.2.2.2, but that also applies to subsequent requests.

Community
  • 1
  • 1
Abhijit Sarkar
  • 21,927
  • 20
  • 110
  • 219