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

Incorrect behaviour with IIIF Image API v2 and full for size #604

Open
ahankinson opened this issue Sep 6, 2022 · 2 comments
Open

Incorrect behaviour with IIIF Image API v2 and full for size #604

ahankinson opened this issue Sep 6, 2022 · 2 comments

Comments

@ahankinson
Copy link

ahankinson commented Sep 6, 2022

When requesting an image using the full parameter, with max_size set, you get a 403 Forbidden response, as documented in #537 .

The workaround suggested is that you use max instead. I believe this is incorrect behaviour. IIIFv2 Image Servers are still expected to support the full parameter, even though it was deprecated (not removed) in v2. A 403 Forbidden response is also not correct, because (AFAIK) it is not tied to a server understanding the request but refusing to authenticate it.

@azaroth42
Copy link

I haven't experienced the actual behavior, but my understanding of the spec is:

full: Try to return the full image at the maximum possible resolution (e.g. image is 5000x5000, then full is a request for 5000x5000)

max: Return the largest size available for the current request, rather than every pixel. (e.g. image source is 5000x5000, but maxWidth or maxLength is 2000, then it returns 2000x2000)

Thus if there is a maxWidth/maxHeight setting which is less than the size of the source image, and full is requested, then it would return an error, as 5000,5000 is greater than the limit of 2000,2000

After some github archaeology, IIIF/api#620 (comment) is where the discussion starts that led to the separation of full and max

@ahankinson
Copy link
Author

ahankinson commented Sep 8, 2022

I experienced the actual error on this image:

https://images.domestic-beethoven.eu/iiif/2/ESS2022%2FBL_Zweig%20MS%2058_1v_O%20du%20eselhafter%20Peierl.png/full/full/0/default.jpg

While I agree that the spec is now clearer in v3, I think the question might be what is "expected" in v2 implementations, prior to the interpretation being clarified. (I put expected in quotation marks to acknowledge that different people probably expect different things). It's definitely better now in v3, but how do we deal with implementations where the interpretation is ambiguous prior to spec clarification?

If full were designed to raise an error when requesting an image under fairly normal operations, I would have expected that to be explicitly called out in the v2 specs, since the spec is otherwise clear on the appropriate error conditions in other places (the spec says that size can return a 400 for zero width / height). If it does, and I've missed it, please let me know!

Instead it simply says it is returned at it's "full" size, which, in the past I have interpreted as the full size available to the user. IIP has this behaviour, which is why I find it surprising when using a Canteloupe server. I can't really imagine a case where getting a 403 error in this case is helpful to the user.

Perhaps one way forward is for Canteloupe to offer "strict" interpretation of full for the v2 API, which can either raise a 403 if enabled, or set it as an alias for "max" if disabled?

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

2 participants