Open Stack

On Mon, 21 Aug 2017, Jay Pipes wrote:
> On 08/21/2017 04:59 AM, Chris Dent wrote:
> We do have cache validation on the server side for resource classes. Any time 
> a resource class is added or deleted, we call _RC_CACHE.clear(). Couldn't we 
> add a single attribute to the ResourceClassCache that returns the last time 
> the cache was reset?

That's server side cache, of which the client side (or proxy side)
has no visibility. If we had etags, and were caching etag to resource
pairs when we sent out responses, we could then have a conditional
GET handler which checked etags, returning 304 on a cache hit.
At _RC_CACHE changes we could flush the etag cache.

> But meh, you're right that the simpler solution is just to not do HTTP 
> caching.

'xactly

> But then again, if the default behaviour of HTTP is to never cache anything 
> unless some cache-related headers are present [1] and you *don't* want 
> proxies to cache any placement API information, why are we changing anything 
> at all anyway? If we left it alone (and continue not sending Cache-Control 
> headers for anything), the same exact result would be achieved, no?

Essentially so we can put last-modified headers on things, which in
RFC speak we SHOULD do. And if we do that then we SHOULD make sure
no caching happens.

Also it seems like last-modified headers is a nice-to-have for that
"uknown client" I spoke up in the first message.

But as you correctly identify the immediate practical value to nova
is pretty small, which is one of the reasons I was looking for the
lightest-weight implementation.

-- 
Chris Dent                      (⊙＿⊙')         https://anticdent.org/
freenode: cdent                                         tw: @anticdent