Image urls with no extension and no content-type header fails

[nickvelloff]

Source image url from Evernote (Media block with cover)
https://www.evernote.com/shard/s31/sh/697b5242-7e79-4565-b1bb-74d9987ed3cb/c591bfd1c137afa6a681bb975f15a5f2/thm/note/697b5242-7e79-4565-b1bb-74d9987ed3cb

Produced url:
https://imgflo.herokuapp.com/graph/...../passthrough?height=720&input=https%3A%2F%2Fwww.evernote.com%2Fshard%2Fs31%2Fsh%2F697b5242-7e79-4565-b1bb-74d9987ed3cb%2Fc591bfd1c137afa6a681bb975f15a5f2%2Fthm%2Fnote%2F697b5242-7e79-4565-b1bb-74d9987ed3cb

Error:
{"errno":-2,"code":"ENOENT","path":"temp/01e69e264a7829dbb17e6bfd0a887b51960f6ad9.jpg"}

[jonnor]

@nickvelloff The URL is incomplete, can you paste again?

[jonnor]

@nickvelloff cannot reproduce that exact error. However I do get a black image output. Looking at the response data from the input URL, it does not set any Content-Header. This combined with no extension means that we don't know which file type is in use.
What needs to be done is to do sniffing on the actual file content header. Which is not something GEGL does at the moment..

[nickvelloff]

So this is a URL that has been consumed by the /share endpoint. Thus any lack of specific image information required is in the flow of the URL data consumption on the API side. Would this be considered a bug I should surface?

On Mar 17, 2015, at 12:47 PM, Jon Nordby notifications@github.com wrote:

@nickvelloff https://github.com/nickvelloff cannot reproduce that exact error. However I do get a black image output. Looking at the response data from the input URL, it does not set any Content-Header. This combined with no extension means that we don't know which file type is in use.
What needs to be done is to do sniffing on the actual file content header. Which is not something GEGL does at the moment..

—
Reply to this email directly or view it on GitHub #23 (comment).

[jonnor]

Browsers handle this case, so should imgflo. Its just a bit tricky with the
libraries we use.

But probably could write a little image type sniffer and run that on the
files before passing over to GEGL.
On Mar 20, 2015 6:09 AM, "Nick Velloff" notifications@github.com wrote:

So this is a URL that has been consumed by the /share endpoint. Thus any
lack of specific image information required is in the flow of the URL data
consumption on the API side. Would this be considered a bug I should
surface?

On Mar 17, 2015, at 12:47 PM, Jon Nordby notifications@github.com
wrote:

@nickvelloff https://github.com/nickvelloff cannot reproduce that
exact error. However I do get a black image output. Looking at the response
data from the input URL, it does not set any Content-Header. This combined
with no extension means that we don't know which file type is in use.
What needs to be done is to do sniffing on the actual file content
header. Which is not something GEGL does at the moment..

—
Reply to this email directly or view it on GitHub <
https://github.com/jonnor/imgflo-server/issues/23#issuecomment-82470894>.

—
Reply to this email directly or view it on GitHub
#23 (comment).

[nickvelloff]

Cool well let me know if you would like me to reproduce the specific payload for testing.

On Mar 20, 2015, at 4:37 AM, Jon Nordby notifications@github.com wrote:

Browsers handle this case, so should imgflo. Its just a bit tricky with the
libraries we use.

But probably could write a little image type sniffer and run that on the
files before passing over to GEGL.
On Mar 20, 2015 6:09 AM, "Nick Velloff" notifications@github.com wrote:

So this is a URL that has been consumed by the /share endpoint. Thus any
lack of specific image information required is in the flow of the URL data
consumption on the API side. Would this be considered a bug I should
surface?

On Mar 17, 2015, at 12:47 PM, Jon Nordby notifications@github.com
wrote:

@nickvelloff https://github.com/nickvelloff cannot reproduce that
exact error. However I do get a black image output. Looking at the response
data from the input URL, it does not set any Content-Header. This combined
with no extension means that we don't know which file type is in use.
What needs to be done is to do sniffing on the actual file content
header. Which is not something GEGL does at the moment..

—
Reply to this email directly or view it on GitHub <
https://github.com/jonnor/imgflo-server/issues/23#issuecomment-82470894>.

—
Reply to this email directly or view it on GitHub
#23 (comment).

—
Reply to this email directly or view it on GitHub #23 (comment).