Support for redirects about shrine-url

[janko]

I updated Shrine::Storage::Url#exists?and Down::NetHttp#open to follow redirects (so switching to Down::Http shouldn't be needed). I released shrine-url 1.0.2 and down 4.2.0 with these changes.

[lcmen]

@janko-m that's great! I will try to switch the backend after the Christmas and let you know if it solves the problem for us.

Thanks again for your excellent support!

[janko]

@lucasm-iRonin Shrine::Storage::Url#download already automatically follows up to 2 redirects by default. Shrine::Storage::Url#open doesn't follow redirects with the default Down::NetHttp backend, though it does with Down::Http and Down::Wget. I will modify Down::NetHttp#open to follow redirects.

Shrine::Storage::Url#exists? also obviously doesn't follow redirects, though it's never used automatically by Shrine, it's only used if the user calls Shrine::UploadedFile#exists?. I could update #exists? to follow redirects, but I think it would even be sufficient to just include 3xx in "successful response codes".

[lucasm-iRonin]

@janko-m thanks for quick reply. I didn't know that following redirects may depend on the backend - we were using the default one which is Down::NetHTTP. I can try to switch to other backend to see if it solves the problem.

The case with dropbox links is quite specific - redirects are single time use. If we use refresh_metadata plugin does Shrine-url will be able to handle that? First download will be necessary to get the file's metadata and then another one will actually download the file - those 2 requests will need to generate a fresh link from the original dropbox link by following the redirect one more time.

[janko]

@lucasm-iRonin Shrine-url will make every request to the original URL (which will redirect to the destination URL), so the destination URL will not be reused.

[lucasm-iRonin]

@janko-m I've just checked it and it works fine. Thanks again!