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

Image returning {} on about 2% of uploads #176

Closed
brad13x opened this issue Jan 6, 2020 · 9 comments
Closed

Image returning {} on about 2% of uploads #176

brad13x opened this issue Jan 6, 2020 · 9 comments

Comments

@brad13x
Copy link

brad13x commented Jan 6, 2020

On about 2% of the images I upload to the s3 the cloudFront url returns {} instead of an image.

Any clues on how to fix this?

@brad13x
Copy link
Author

brad13x commented Jan 7, 2020

I believe its having an 'x' in the filename.

@jensnylander
Copy link

Yes I can confirm having x in the filename returns {}

@beomseoklee
Copy link
Member

We have updated our solution, and I believe your issue has been fixed. If you still see the issue with the latest version (v4.2), please feel free to reopen the issue.

You can refer to the recent changes here

@brad13x
Copy link
Author

brad13x commented Feb 6, 2020

@beomseoklee what is the best way to update on AWS?

@beomseoklee
Copy link
Member

If you don't mind to create a new stack, it would be better to launch the new one. If you wish to keep your old one, I would say you can update the stack with the latest template, which is https://s3.amazonaws.com/solutions-reference/serverless-image-handler/latest/serverless-image-handler.template

With the new template, I believe your Lambda function would be updated as well.

@shortdoormedia
Copy link

I am not sure this was fixed entirely. I have the following examples:

Works:
130A0364_320x213.jpg
130A0364320x213.jpg

Doesn't Work:
130A0364-320x213.jpg

@shortdoormedia
Copy link

I think the issue is in the mapping regex. It views the path as "-400x400" dimensions

Screen Shot 2020-03-18 at 6 24 18 PM

@beomseoklee
Copy link
Member

@shortdoormedia Do you use the resizing? For example, https://YOUR_URL/400x400/test-400x400.jpg? If you don't, I guess -400x400 would be your resizing method which is not supported option (minus value).

@shortdoormedia
Copy link

shortdoormedia commented Mar 18, 2020

@beomseoklee we have a unique scenario where we are transitioning from an old CDN to a new one and have a flat directory with files containing names like /test-100x100.jpg. They were linked to statically without any resizing method.

What I have done is updated our lambda function to find a request uri without resizing and a path with dimensions and applying that as the fit-in. Deploying now to see if it works:

//This assumes a request like: /original/130A0368-160x106.jpg
//and rewrites the request to:  /fit-in/160x106/130A0368-160x106.jpg

//Get the original image file name
const image = request.uri.split('//').pop().split('/').pop();

//Get dimensions object
const dims = image.match(/[^\/]\d+x\d+/g);

//Get dimension and replace a leading hyphen note you may need to change this
const dim = dims[0].replace('-','');

//Define your fit-in sizing or what ever plus size from file name
const replace = 'fit-in/'+ dim + '/';

//Replace 'original' with replace
request.uri = request.uri.replace('original/',replace);

//Return
return request;

Edit fix errors and formatting x 20 times

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

No branches or pull requests

5 participants