Resolve redirects early

[icidasset]

For performance reasons, it would be ideal to resolve redirects of the given url.

Example scenario:

• User provides url to Google Drive content
• That url redirects to another url

Whenever this library makes a range request it uses the original url given by the user. But ideally we should used the "resolved redirect" url. There don't have to be much changes for this, we can get the resolved url from the initial HEAD/GET (fetch) request response.

// Basically
fetch().then(response => resolvedUrl = response.url)

(note: This may be resolved in the newer versions of this library, I should double check)

[Borewit]

This question leads to more questions.

Having a look to Diffuse dependencies, you are using remotestoragejs to sync or access Cloud audio files.

Why is this issue limited to Google Drive?

Just to get in sync with me. please have a look to @tokenizer/s3 and how this can be used.

Note that @tokenizer/s3 is utilizing the abstract module @tokenizer/range. So @tokenizer/range can be used to map to other chunk / range based clients.

Similar to the @tokenizer/s3, maybe it is worth to implement a @tokenizer/google-drive?

Or use an abstract storeage provider in betweeen, like:

• remotestoragejs
• or uppy?

Having a quick look to those API's, I don't see a way to read a range. This is the way, to make music-metadata(-browser) read the metadata efficient over a wide area network.

To understand where we are now, in you current implementation, can you confirm you actually utilizing the HTTP-range mechanism @icidasset?

[icidasset]

Sorry if I caused any confusion, this is not limited to Google Drive at all (hence "example scenario").

---

Diffuse definitely uses the HTTP-range mechanism, and only needs tokenizer-http. tokenizer-s3 is cool, but not needed in Diffuse. Because Diffuse needs to do other things with S3 as well, like making a file tree. Does that make sense?

So for me personally, no need to implement @tokenizer/google-drive or other variants. Could be useful to other people perhaps, but not for Diffuse 😉

Sidenote: Remotestorage is optionally used in Diffuse to store the user's data, such as playlists, it's not used for music storage. With optionally I mean, the user chooses specifically where they want to store their data, remoteStorage is one option (see Diffuse's sign-in screen).

---

To come back to the original issue.
Let me make a quick PR for this, I think this'll be super easy to solve.