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

Crop cut "Bad extract area" #29

Open
francesconero opened this issue Nov 14, 2016 · 3 comments
Open

Crop cut "Bad extract area" #29

francesconero opened this issue Nov 14, 2016 · 3 comments

Comments

@francesconero
Copy link

Sharp returns a "Bad extract area" when extracting "out of bounds" portions of images. This means that requesting a bad cut makes the server return a 500 code. This is not really ideal for a production environment.

Wouldn't it be better to simply return a sensible default (like ignoring the crop or switching to a different crop mode) while issuing a 400 (as in a "Bad request" was made)?

@teohhanhui
Copy link
Contributor

What about returning 404 to indicate that the requested size is not
available?

On Mon, 14 Nov 2016, 19:58 Francesco Nero, [email protected] wrote:

Sharp returns a "Bad extract area" when extracting "out of bounds"
portions of images. This means that requesting a bad cut makes the server
return a 500 code. This is not really ideal for a production environment.

Wouldn't it be better to simply return a sensible default (like ignoring
the crop or switching to a different crop mode) while issuing a 400 (as in
a "Bad request" was made)?


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#29, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAhf60rLwO0IZ_QMgB5_gY3b9vsNxGhkks5q-EzzgaJpZM4KxPfG
.

@francesconero
Copy link
Author

francesconero commented Nov 14, 2016

Makes sense as well. Would you provide an alternative image or just return the status code without content?

Sorry if kind of off-topic: when using a resizing crop mode (like cfill) the crop focus (x and y) are interpreted as referring to the resized image and not the original, correct? This makes it a little clunky client side as in first you need to figure out the resized image dimensions (the crop usually has a different aspect ratio so you can't use the crop dimensions) and then calculate the crop focus on the resized image dimensions.

What do you think about requiring x y parameters to be provided as referring to the original image size dimensions?

Sorry for the convoluted explanation, I hope you understood what I mean.

@teohhanhui
Copy link
Contributor

404 should not return an image.

I agree that the cropping needs to be reworked, especially cpad which is just wrong.

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

No branches or pull requests

2 participants