Fetching Manifests does not follow 300 redirects about clover-iiif HOT 6 OPEN

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.

from clover-iiif.

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.

from clover-iiif.

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.

from clover-iiif.

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.

from clover-iiif.

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.

from clover-iiif.

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.

from clover-iiif.