Issue with redirect for v2 images

[glenrobson]

I'm just looking at updating the iiif training to use the new IIIF service and I noticed the following IIIF image URL isn't working:

https://iiif.archivelab.org/iiif/img-8664_202009/info.json

To get it to work you need the ID plus the name of the filename:

https://iiif.archive.org/image/iiif/2/img-8664_202009%2FIMG_8664.jpg/info.json

This image is included in one of the tests:

https://github.com/internetarchive/iiif/blob/96ce8358532e97f984da59bcef585f8f12e4f3aa/tests/test_cantaloupe_resolver.py#L6

so the resolver does resolve it. Actually it looks like this manifest doesn't show either:

https://iiif.archive.org/iiif/2/img-8664_202009/manifest.json

but the v3 does:

https://iiif.archive.org/iiif/3/img-8664_202009/manifest.json

[digitaldogsbody]

The redirect code is not on the versioned endpoint, perhaps we should add it. In the meantime simply switching from archivelab to archive is enough to get the redirect and add the filename: https://iiif.archive.org/iiif/img-8664_202009/info.json (it's currently redirecting to the domain with .prod. in it, but that is a separate issue)

[glenrobson]

Perfect thank you!

[digitaldogsbody]

I can look at the issue with the v2 manifest, it's probably the same issue as #16

[glenrobson]

It looks like we are missing a CORS header in the redirect:

 curl -v "https://iiif.archive.org/iiif/img-8664_202009/info.json"
> GET /iiif/img-8664_202009/info.json HTTP/2
> Host: iiif.archive.org
> User-Agent: curl/8.1.2
> Accept: */*
> 
< HTTP/2 302 
< server: nginx/1.23.2
< date: Mon, 25 Sep 2023 14:03:33 GMT
< content-type: text/html; charset=utf-8
< content-length: 353
< location: https://iiif.prod.archive.org/image/iiif/2/img-8664_202009%2fIMG_8664.jpg/info.json
< cache-control: max-age=900
< 

Which is stopping this from working: https://iiif.gdmrdigital.com/openseadragon/index.html?image=https://iiif.archive.org/iiif/img-8664_202009/info.json

[digitaldogsbody]

Ah of course - we removed the CORS headers from nginx due to there being issues with duplicates created by Cantaloupe.

There is some code in the Python app which adds them manually to responses that come through ldjsonify: https://github.com/internetarchive/iiif/blob/main/iiify/app.py#L188

We also already have Flask-CORS setup, but it is enabled only if there is a config key: https://github.com/internetarchive/iiif/blob/main/iiify/app.py#L19 and it looks like the default is False (https://github.com/internetarchive/iiif/blob/main/iiify/configs/__init__.py#L44), so I think we can fix this easily in one of two ways:

1) Change the default or override it with a local config in the production deployment (we might have to remove the code in ldjsonify in this case to prevent double headers)

2) Add similar code to the redirects - I am a leaning away from this because at that point we are basically adding CORS to every response manually, rather than taking advantage of the Flask-CORS wrapper that will do it for us and prevent this issue arising with other endpoints.

[glenrobson]

Great now works on the test instnace:

https://iiif.gdmrdigital.com/openseadragon/index.html?image=https://iiif.ux-fnf-misc.archive.org/iiif/img-8664_202009/info.json