Allow browser caching of ORES API responses

[Krinkle]

Following up on https://github.com/wiki-ai/ores/issues/45#issuecomment-122380069, it would be nice if some Cache-Control headers were added to the response by the ORES API web service.

Right now when making the same request multiple times it reaches to ORES each time. Something basic like Cache-control: public, maxage=300, would make a good start.

In addition (or alternatively) output an E-Tag header (e.g. set to he digits of a SHA1 digest of the JSON output - or something more sophisticated). This way browsers will pass it back in the form of If-None-Match, which the application can respond to by short-circuiting the response as 304 Not Modified - which saves a bit of bandwidth.

The latter has the benefit of working regardless of any fixed max-age (e.g. during first 5min the browser will use its cache without server roundtrip. After 5 minutes, the next request goes to the server with If-None-Match header and either gets back a short 304 response indicating the cache can be re-use, or it will use contents of the fresh 200 OK response).

[Krinkle]

It seems this is still the case. And appears intentional, based on #165.

response.headers['Cache-Control'] = \
           "no-store, no-cache, max-age=0"`

https://ores.wikimedia.org/v3/scores/nlwiki/damaging/10001 https://ores.wikimedia.org/v3/scores/nlwiki/10001/damaging

cache-control: no-store, no-cache, max-age=0

/cc @halfak

[halfak]

Thanks for the report! Caching here is weird because we need to be able to communicate when a model version changes that the cache should be renewed. Do you think we could somehow provide a different cache key or something like that when a model changes? I'm not clear on how browser caching works.

[halfak]

See https://phabricator.wikimedia.org/T251004