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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
