Some of the links in iiif-universe.json have issues of a few different kinds. I found three kinds of problems
- Some simply return 404, 500 or some other error page and so just do not work at all.
- Some use http instead of https. If the viewer is served over https you get mixed content errors. Most of these would actually redirect to https but due to the mixed content problem the browser won't get that far.
- One endpoint works otherwise but has no CORS policy so cannot actually be used in any viewer.
Here are the details
- Yale: uses http, no redirect and invalid certificate in https version
- Yale Center for British Art: Error page, does not work at all
- Stanford: No CORS policy
- e-codices: uses http which gets redirected to https, internal URIIDs are https
- Chronicling America Newspapers by State: 404
- Sentences Commentary Text Archive: uses http which gets redirected to https, internal IDs are http which again then get redirected
- Villanova University: uses http, redirects to https, internal IDs are https
- Wellcome Library: uses http, redirects to https, internal IDs are https
- The Internet Archive: Internal server error
- Biblissima: uses http, redirects to https, internal IDs are http which again redirected
- Shared Shelf Commons: error page
- Jubilees Palimpsest Project: uses http, no redirect and invalid certificate in https version
I suggest removing the links that just don't work at all. If someone knows, or can find out, updated links then fixing them would of course be preferable to removing completely.
I also suggest that for all the ones which redirect to https and internally use https, the endpoint in iiif-universe.json should instead just have https. This would avoid the mixed content problem and https appears to be their preferred way of access anyway. In addition, currently iiif-universe.json has a collection with ID http://something but when you resolve that you get a collection with ID https://something, which technically is a different object and so the IIIF is broken. Having https to start with would avoid this as well.
The ones which redirect to https but internally use http are trickier. Changing the endpoint to https instead would just move the mixed content problem elsewhere. Also, you would have the problem of https references returning objects with http in the ID. So I suggest leaving these as is. Also obviously no changes should be made to the other ones which use http and have no working https version.
For the Stanford collection, which has no CORS policy, it technically works fine but in practice cannot actually be used. So could go either way, either remove or leave it.
I am happy to make the changes and submit a PR if these suggestions sound good.