billmalarky/react-native-image-cache-hoc

Error: url has invalid file extension

Closed this issue · 4 comments

I suspect this library isn't able to handle URLs with query strings?

e.g. https://firebasestorage.googleapis.com/v0/b/.appspot.com/o/user-images%2F9666dfbe-0b6e-46de-9fc7-e41391c9dd2c.jpg?alt=media&token=2c7f555a-57be-48ff-a3e9-a457fcd05ee0

The library throws the error "Error: url has invalid file extension"

Cheers & good work so far!

It has rather naive file extension validation associated with the passed in url.

https://github.com/billmalarky/react-native-image-cache-hoc/blob/master/lib/FileSystem.js#L139

I'll update it to strip the query string as well as a quick patch, but the real solution is validating the actual downloaded file as a jpg/gif/png instead of validating using a file name extension (which doesn't even necessarily mean the file is what it says it is).

Or maybe I should remove this validation from the library entirely and leave validation up to the developer who integrates the library since true file validation will incur a slight performance hit.

Update: Recalling now the extension is required to be pulled and then set to local file hash filename extension, so this logic has nothing to do with mime type validation.

Patch could involve updating file extension extraction with a url parses to get a clean path to pull ext from:

https://www.npmjs.com/package/url-parse

Alternatively if no extension is set on url, fallback to determining ext from content/type http header.

While I'm here I may as well include bmp in the allowed types since native <Image> supports bmp.

The currently supported formats are png, jpg, jpeg, bmp, gif, webp (Android only), psd (iOS only).

https://facebook.github.io/react-native/docs/image.html

@billmalarky I think stripping the query string to grab the file extension is a decent short term solution - still need the query string when actually fetching the image though.

There will almost certainly be a case whereby the file extension isn't in the URL. Like you said I don't think this library should be solving file type validation.

Patched in: 0c690b0

Deployed in version 1.2.3

Alternatively if no extension is set on url, fallback to determining ext from content/type http header.

Added this functionality in 1.3.0. 21fd653