Check ETag on 200 response when checking if configuration setting has changed

[amerjusupovic]

Currently, if the provider makes a request to get configuration settings using the If-None-Match header, it considers any response with a status code of 200 to mean that the queried settings have changed in the App Configuration store. However, HTTP caching rules state that if a request gets 304 but the cache has a corresponding value, it will return a 200 status code instead. This means that we would be unnecessarily refreshing the configuration in that case, which could be prevented by always checking the ETag to see if anything has changed instead of only the status code.

[Eskibear]

It makes sense for sentinel-based key-values refresh as we cache etags for sentinels. Just curious what would be the case for page etags? I don't think we cache page etags for each page for each selector, that would be too much. Or we just skip the optimization in this case?

[amerjusupovic]

We don't cache the page etags at the moment, but in order to offer the functionality we want in #536 we would have to do so if someone were to call the RegisterAll API, like I added in #574. If they don't call that API, I don't think the optimization is reasonable outside of sentinel refresh, like you said.