-
Notifications
You must be signed in to change notification settings - Fork 105
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
Comments
I haven't experienced the actual behavior, but my understanding of the spec is:
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 |
I experienced the actual error on this image: 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 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 |
When requesting an image using the
full
parameter, withmax_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 thefull
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.The text was updated successfully, but these errors were encountered: