-
Notifications
You must be signed in to change notification settings - Fork 0
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
Fails to Return Images for Certain Items in Fedora #1
Comments
I can confirm that the same image exists on the DEV server and it works fine. However, there also appears to be existing upstream bug that describes nearly this exact issue: And there is this related issue: This is fixed in v5.0.6: I suggest upgrading Cantaloupe.
to purge a specific item. |
Another possible cause are these permanent redirects.
However, a working URL (like https://projectmirador.org/embed/?iiif-content=https://api.library.tamu.edu/iiif-service/fedora/presentation/3b/6f/c3/25/3b6fc325-f6ca-41d8-b91e-8c5db3be8c13/london-collection_objects/10) produces:
|
I have also observed this stack trace in the logs:
|
Looking at the manifest, the thumbnail at least works:
But changing it to a
Results in a 0-byte length (empty) PNG file of the thumbnail. The first link (the JPG), which works, does not cause a log in the IRIIIF service on refresh.
|
The (forked) cantaloup is also behind: |
PROD likely has a mis-configuration where the fallback processor is being set to a stream processor:
According to the documentation on fallback processor:
A StreamStrategy probably should be used here and is likely not valid as a fallback. |
The data was brought in from PROD to PRE. I think many of the bad images are a result of incorrectly imported collections or bad cache. |
Certain images stored in Fedora and presented in an exhibit do not load in the Mirador viewer.
For instance, here is a work in one of our exhibits. Here is the tif that should be loaded by the image server in Fedora.
While the image is downloadable, it's not visible when it's served via Cantaloupe. For instance, here is its parent manifest, and here is that manifest loaded in mirador:
https://projectmirador.org/embed/?iiif-content=https://api.library.tamu.edu/iiif-service/fedora/presentation/3b/6f/c3/25/3b6fc325-f6ca-41d8-b91e-8c5db3be8c13/london-collection_objects/9
As you can see, the image doesn't load. Let's take a closer look just at Cantaloupe.
This is the Cantaloupe Image API Response.
We can request the full image like this.
When we do that, the image server returns a 0 byte object and an HTTP
200
response. If we request a smaller version of that same image, the same thing happens.This appears to happen with any request toward this base image; the server responds with a 200 and a 0 byte object.
Acceptance Criteria
200 Success
response for certain resources like the one above so that we have documentation on how to address when this problem occurs in the future.The text was updated successfully, but these errors were encountered: