Broken tile URLs?

[edsu]

I noticed that manifests that were displaying in the recent past no longer seem to display? Here's an example manifest:

https://iiif.archivelab.org/iiif/naeb-b101-f02-23/manifest.json

Here's what it looks like in the Universal Viewer:

https://uv-v4.netlify.app/#?manifest=https://iiif.archivelab.org/iiif/naeb-b101-f02-23/manifest.json

Viewing the browser console you can see there are a lot of 404 errors for tiles?

Here's an example of one of them: https://iiif.archivelab.org/iiif/naeb-b101-f02-23$0/1024,2048,1024,1024/256,/0/default.jpg

Did the URL generation or routing change recently?

[digitaldogsbody]

The old archivelab infrastructure shouldn't have changed at all (at least, we haven't altered the code for it as part of the IIIF-C co-ordinated work).

The good news is you can get the images from the shiney new Cantaloupe powered service by replacing archivelab with archive in the URL: https://iiif.archive.org/iiif/naeb-b101-f02-23$0/1024,2048,1024,1024/256,/0/default.jpg

You'll get a redirect to the new identifier format that uses the filepath within the item rather than the $<leafnum> format: https://iiif.archive.org/image/iiif/2/naeb-b101-f02-23%2fnaeb-b101-f02-23_jp2.zip%2fnaeb-b101-f02-23_jp2%2fnaeb-b101-f02-23_0000.jp2/1024,2048,1024,1024/256,/0/default.jpg

[jeffreycwitt]

I'm justing noticing this now. I think the "archivelab" part suddenly stopped working.

The following works: https://iiif.archive.org/image/iiif/2/operaomni09duns%2foperaomni09duns_jp2.zip%2foperaomni09duns_jp2%2foperaomni09duns_0005.jp2/full/full/0/default.jpg

But this does not: https://iiif.archivelab.org/iiif/image/iiif/2/operaomni09duns/operaomni09duns_jp2.zip/operaomni09duns_jp2/operaomni09duns_0005.jp2/full/full/0/default.jpg

The main issue is that the `iiif.archivelab.org" persists in the v2 manifests, but not in the v3.

Compare the v3 version:

https://iiif.archive.org/iiif/3/operaomni09duns/manifest.json

to the v2 version

https://iiif.archive.org/iiif/2/operaomni09duns/manifest.json

and inspect the image service ids

[jeffreycwitt]

I suggested making this change...https://github.com/internetarchive/iiif/pull/62

But i'm not that familiar with the codebase

[jeffreycwitt]

I just did the following to get my downloads to succeed:

fullid = fullid.gsub("archivelab.org", "archive.org")

[digitaldogsbody]

We have talked about fixing the v2 manifests to use the new URLs, and also updating Canvas identifiers etc (see variously discussion in https://github.com/ArchiveLabs/iiif.archivelab.org/issues/92, https://github.com/internetarchive/iiif/issues/28, https://github.com/ArchiveLabs/iiif.archivelab.org/issues/74 and various bits of the community notes doc).

At the minute, updating the old v2 code is considered out of scope for the work we are doing (https://github.com/internetarchive/iiif/issues/41) but the one change we have made is switching to Cantaloupe for handling requests to the "old" endpoint for images.

This means at some point (as yet unspecified) the plan is to redirect iiif.archivelab.org to iiif.archive.org, so existing identifiers will continue to work, but using the new service.

Once all this is in place, we might consider revisiting the v2 code to see if we can fix a few of the legacy issues.

[digitaldogsbody]

Just to add, by the way, it's probably not broken URLs. The old service does all the tile generation itself, and it has some code that bails out with a 404 if there's any kind of exception: https://github.com/ArchiveLabs/iiif.archivelab.org/blob/master/iiify/app.py#L149-L150.

I've passed on a message to the IA crew so hopefully someone will be able to give the old service a look over soon, but in the long run updating to use the new iiif.archive.org service is the best bet.

[edsu]

Thank you for the quick attention. It seems like upgrading to v3 is the best way forward. It's great to see the service migrate out or labs to the stable domain!