Caching headers

[danielrichman]

We should probably set some. The response is not really cacheable for longer than a few minutes, due to release of new dataset.

[danielrichman]

If we don't trust browsers, we might want to tell them to never cache. We can give Varnish caching advice via other headers if necessary later on...?

[rjw57]

How about an etag which is a hash of (dataset which would be used) + (launch parameters)? That should be safe since we can then make the decision for the browser.

[rjw57]

(And then maybe some sort of 30-60 second age for GET requests so that Varnish can help against /.-ing.)

[danielrichman]

I do like the ETag header idea but I think it solves a different problem to
the one I was thinking of. Someone rerunning a prediction is atypical,
probably?

Isn't our api via POST? Will browsers even cache these reqs?

I was mainly thinking about what happens if someone publicly shares a
prediction URL; the varnish thing.

...actually some googling suggests that varnish can't cache post either >_>
On 21 Nov 2014 15:42, "Rich Wareham" [email protected] wrote:

(And then maybe some sort of 30-60 age for GET requests so that Varnish
can help against /.-ing.)

—
Reply to this email directly or view it on GitHub
#76 (comment)
.

[rjw57]

The v1 API does everything via GET which should be cache-able.

[danielrichman]

You are absolutely correct. I was confused (and at Maths happy hour) so somehow convinced myself that we were POSTing JSON.

So I think my other point stands: I don't think the ETag idea is worth it, because it probably won't yield a very high hit rate at all, and the request still has to go through to Python. We just need some sensible cache headers for varnish to use in case we have a burst and need to switch it on?