Omeka S dies when trying to add too-large IIIF image

[crism]

When importing an IIIF image, e.g. from here, Omeka S constructs a URL. If the image at that URL is larger than the allowed maximum, the IIIF server will return a 403 Forbidden response. Omeka S does not check for this, and when it tries to delete the temp file, it crashes.

[crism]

PR #1194 fixes the crash. A more robust fix would detect the 403 response and fall back to a smaller version of the file; I’m not conversant enough with the IIIF API to implement that right now.

[zerocrates]

Yeah, we may need to switch to picking something out of sizes.

My understanding is also that full is going away in a future version of the IIIF spec so it might be in our best interests to switch to a different form for the thumbnailing URL now.

[bencomp]

I may be missing something here, but one of the features of the IIIF Image API is that you can request images in smaller sizes, for example to use as thumbnails. So instead of downloading a full-size image and resizing it on the side of Omeka S, I would recommend to download a thumbnail-sized image. Or is that what you were saying, @zerocrates?

[zerocrates]

So, the problem for us here is just that IIIF image servers can support various subsets of the spec features. The full/max size is (supposedly) guaranteed to be supported even by the lowest levels of compliance with the spec, so that's what we use.

Obviously there's the idea that we could use the IIIF features themselves to get the size we want directly, but that resizing is not guaranteed to be available either.

Some version of this that depended on the sizes to be present, or looked at what features the server advertises support for to then try to use them, could be possible, but I'm not sure either provides a whole lot of practical benefit.