Fetching Manifests does not follow 300 redirects

[garrettdashnelson]

I'm eager to use Clover for a new web project. However, I'm finding a fetch error in cases where a Manifest's @id URI points to a permalink server which in turn returns an HTTP redirect back to the original Manifest.

Example: passing this Manifest to the Viewer component:

<Viewer iiifContent="https://www.digitalcommonwealth.org/search/commonwealth:x346gm94s/manifest" />

The Manifest's @id points to an ARK permalink at https://ark.digitalcommonwealth.org/ark:/50959/x346gm94s/manifest

Sending a GET request to that ARK permalink returns a 302 Found HTTP response with the Location back to the original at https://digitalcommonwealth.org/search/commonwealth:x346gm94s/manifest

Trying either of these URIs — the original Manifest or the ARK permalink ID — in other IIIF viewers (e.g., Universal Viewer or TIFY) works just fine, so it's not a CORS problem.

[mathewjordan]

Hi @garrettdashnelson and thank you for inputting this.

I'd love to solve this issue for you and am debugging our Manifest request process. I've abstracted out how this works here and am modeling possible solutions using your scenario as a fixture: https://codesandbox.io/s/vault-debug-633m8s?file=/src/App.js

Clover is fairly hooked into IIIF Commons libraries, especially Vault. It utilizes this to normalize manifests and upgrade from presentation 2.x => 3.

[garrettdashnelson]

Thanks for looking into it, @mathewjordan! I suspected that it was possible downstream issues in Vault that might have been causing some of the issues. I'm going to try to poke at it myself when I can, but I couldn't obviously figure out why the fetching wasn't simply following the 300 redirect.

[mathewjordan]

Hi again @garrettdashnelson. Just to clarify, I don't think it is specifically a Vault issue -- rather I was abstracting out our manifest retrieval process from the Clover code. I'll take a deeper dive into over the next few days.

[garrettdashnelson]

Cool, thanks a ton @mathewjordan and let me know if I can be helpful — appreciate your willingness to look into it! I'm excited to implement Clover in my next project if I can figure out this Manifest fetching issue.

[alexandergknoll]

Hey @mathewjordan - really appreciate you reaching out re. the project we're working on. It looks to me like the issue is related to @iiif/vault when parsing the URI for the resource. Our manifests returning an ARK permalink for the @id attribute, but they redirect with a 302 to a different location such as in the example @garrettdashnelson posted above. I believe it is this mismatch between that destination and the URI in the @id attribute for the manifest that causes the fetch to fail.

[garrettdashnelson]

Hi @mathewjordan and I'm glad you noticed our use of clover-iiif in the ARGO project! Per the original note in this issue, I think the problem is stemming from a case where the @id defined in the Manifest points to a permalink URL, which in turn returns a 302 Found HTTP response back to the URL which has the actual JSON content of the Manifest. Somewhere in the process of clover-iiif fetching the Manifest, this redirect pattern is not being correctly parsed. @alexandergknoll's patch simply forces vault to treat the id as the exact Manifest URL that is passed to it, ignoring whatever @id is defined in the content of the Manifest.