using HTTP HEAD request to invalidate cache

[hixfield]

As far as I can see, the image caching does not check if the image stored in the local cache is still up to date with the image on the server (in case its a downloaded image of course). I think it would be a good addition to use the HTTP HEAD request (this sends you the headers => last motif timestamp back without the actually large image data itself) to verify if the image is outdated and in that case perform a new download from the server.

[jshier]

We likely don't want to do this manually but allow for some way to reissue the network request for a cached image so the server can tell us one way or another. One of the benefits of a non-persistent cache is that the app will redownload the images when it's relaunched anyway. We'll investigate this for the future.

[hixfield]

Indeed needs investigation! It might be a good idea to not only support a HEAD request but also allow a custom closure to specify if the cache is still valid or if the image should be re-downloaded. I just had a project where the images ware downloaded via HTTPS (AlamofireImage) but the last modified timestamp of the image was checked via a Firebase API call...

[cnoon]

It would be terribly inefficient to issue HEAD requests every time rather than load directly from the queue. Instead, we would want to expose the ability to ignore the cached image to force the image to re-download. As a non-convenient workaround, you could dig into the URLCache directly and remove the cached response before making the request if it's a blocker type issue.