ontodev / droid

DROID Reminds us that Ordinary Individuals can be Developers
BSD 3-Clause "New" or "Revised" License
4 stars 1 forks source link

Consider adding ETag support #97

Closed jamesaoverton closed 3 years ago

jamesaoverton commented 3 years ago

It's often useful to know whether a file has been modified since the last request. The usual HTTP mechanism for this is ETags

https://en.wikipedia.org/wiki/HTTP_ETag

There's a Ring middleware for this that might work out-of-the-box:

https://github.com/deps-app/ring-etag-middleware

Since I mainly care about ETags for views of files that DROID is serving, and not HTML pages that DROID constructs, this File-focused approach is probably fine. If that middleware doesn't work, it shouldn't be hard to implement ourselves.

lmcmicu commented 3 years ago

I can see the value of this as a way to improve server performance. Is this the reason why we want this? Or is the point here to guarantee that we always get the most up-to-date version of the file?

If it is the former reason (or some other reason), then ok. If it is the latter reason, note that DROID should already be guaranteed to get the latest version of the view. This is because we add the header: "Cache-Control" "no-store" to the request when we ask for a view. See this block of code. Of course that is not as efficient as using ETags, so doing that would likely be a performance improvement (unless there is some overhead cost associated with adding the middleware).

jamesaoverton commented 3 years ago

This is my use case: DROID has created some largish file and I download it to some other server A, maybe using curl. Then some time later I want to update that file on server A, but only if it has changed. If DROID supports ETags, then I can just curl -X HEAD and compare to the previous ETag to see if the file has changed. Without something like Etags, every time I want to check for an update I need to download the whole file.

lmcmicu commented 3 years ago

Makes sense.