search

imgflo / imgflo-server

HTTP image processing server based on imgflo
48 stars 7 forks source link

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

Open nickvelloff opened 9 years ago

nickvelloff commented 9 years ago

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 commented 9 years ago

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

jonnor commented 9 years ago

@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 commented 9 years ago

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.

jonnor commented 9 years ago

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 https://github.com/jonnor/imgflo-server/issues/23#issuecomment-83904949.

nickvelloff commented 9 years ago

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 https://github.com/jonnor/imgflo-server/issues/23#issuecomment-83904949.

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