Question about 304 NotModified

[gottfrois]

I have the following scenario:

1. GET some url, returns a cacheable (for couple seconds) result with proper headers
2. GET same url within cached timeframe, does not hit the server, returns response directly from cache (great)
3. GET same url when cache has expire, sends the request to server, server respond with a 304 no-cache.
4. Middleware trace is valid, store, meaning it re-stored the original response back into cache store (great)
5. GET same url within cached timeframe, should not hit the server but it actually re-validate the response.

Why is that? Since the last validate, the server respond with a 304 and the gem re-stored the response into the cache store. It should be able to pickup the cached response directly, at least while the cache entry is still fresh.

I think the issue is that when the gem ask if the entry is fresh here it's based on the max-age which is nil since it was a 304 with no-cache.

But correct me if I'm wrong, the no-cache statement is just for the 304 request, because you don't want to cache a 304 since it has empty body, but it does not mean you should not re-store the original response right?

Hope what I wrote is understandable..

Thanks!

[lucasmazza]

Hey @gottfrois given your steps, sounds like the re-stored response is keeping an outdated Date header, and so the cache is re-validated when it should it. Does your server returns the Date header on the 304 response?

[blocknotes]

Same problem for me.

In our API we return status code 304 for a cached resource but faraday-http-cache says it is uncacheable because it's not in the CACHEABLE_STATUS_CODES:

https://github.com/plataformatec/faraday-http-cache/blob/master/lib/faraday/http_cache/response.rb#L20

Is this correct?