Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support URLs #89

Closed
timholy opened this issue Oct 31, 2016 · 9 comments · Fixed by #302
Closed

Support URLs #89

timholy opened this issue Oct 31, 2016 · 9 comments · Fixed by #302

Comments

@timholy
Copy link
Member

timholy commented Oct 31, 2016

Right now you can't supply a URL for a filename; you have to download and then load. What do people think about having that be more transparent?

If folks like that: since I'm pretty net-naive, what would be the best thing to search for? Should we require that the string begins with "http://" or "https://"?

CC @alanedelman

@StefanKarpinski
Copy link
Member

I strongly object to supporting this with plain strings – it's a huge security hole and means that you can't, based on type analysis, know if code is going to try to hit the network or not! I would be in favor of using a URL type for this instead so you would do URL("https://example.com/data.csv"). That's almost as concise and allows us to use dispatch to handle the case of fetching data.

@Keno
Copy link
Member

Keno commented Oct 31, 2016

https://github.com/JuliaWeb/URIParser.jl would be the standard for that.

@timholy
Copy link
Member Author

timholy commented Oct 31, 2016

Thanks, folks---great tips.

@nlw0
Copy link

nlw0 commented May 19, 2019

I am trying to load an image from the web. Is the recommended way right now to actually save the data to a file and then load from the file? I would like to decode straight from the file contents in memory. Is there any plan to support something like this with ImageMagick, or is it a better idea to just go for a wrapper to the C libraries?

@timholy
Copy link
Member Author

timholy commented Aug 25, 2019

Perhaps we should add URIParser as a Requires dependency and have this download the file to a temporary location. Thoughts? Care to tackle it @nlw0?

@nlw0
Copy link

nlw0 commented Aug 25, 2019

Eventually someone pointed me out to the "secret" ImageMagick.load_ function, and I've been a happy user ever since...

@oxinabox
Copy link
Contributor

It is practically really not as simple as it might seem for FileIO.jl to handle this with just the URI.
Because the file-extension often matters for how FileIO works.

And getting the filename (and thus extension) is more complex than one might think.
The first half (about 70lines) of this file is dedicated to using HTTP.jl's systems to work it out.
And it still has edge cases it gets wrong (e.g. you are allowed to use fairly arbitrary character set encodings for some of the fields)
https://github.com/JuliaWeb/HTTP.jl/blob/master/src/download.jl

@EricForgy
Copy link

It is practically really not as simple as it might seem for FileIO.jl to handle this with just the URI.

How about a data URI?

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

I'm currently having some trouble because I receive an image from the browser as a data URI, e.g.

"data:image/jpeg;base64,long-base-64-encoded-string"

and I want to load this into Images.jl preferably without saving it to a file.

The Julia type could be something like:

struct DataURI
    media
    attributes
    binary
    data
end

I'm kind of stuck on this 😔

@timholy
Copy link
Member Author

timholy commented Sep 4, 2019

For common image formats we can use magic bytes. And any format that doesn't have magic bytes is devil-spawn 😈. There are only so many 3-letter combinations out there, I am amazed that people don't always make use of magic bytes.

timholy added a commit that referenced this issue Mar 3, 2021
User must load HTTP manually for this to be activated.
(It exploits Requires.)

Closes #219
Closes #89
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants