Open nickvelloff opened 9 years ago
@nickvelloff The URL is incomplete, can you paste again?
@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..
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.
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.
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.
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"}