Utrecht University Library Special Collections: missing CORS header and IDs mismatch

[sammeltassen]

Access-Control-Allow-Origin: * CORS header is missing for images.

From the IIIF Image API 2.1.1 documentation:

Servers should send the Access-Control-Allow-Origin header with the value * in response to information requests. The syntax is shown below and is described in the CORS specification. This header is required in order to allow the JSON responses to be used by Web applications hosted on different servers.

Source: https://iiif.io/api/image/2.1/#image-information-request

Example info.json:

• https://objects.library.uu.nl/fcgi-bin/iipsrv.fcgi?IIIF=/manifestation/viewer/13/61/39/136139185182741493007400906779095484903.jp2/info.json

Example image request:

• https://objects.library.uu.nl/fcgi-bin/iipsrv.fcgi?IIIF=/manifestation/viewer/13/61/39/136139185182741493007400906779095484903.jp2/full/1000,/0/default.jpg

Image in special collections portal

[sammeltassen]

Since March 28 Utrecht University Library has also implemented the Presentation API. The IIIF Manifests do not load in the Allmaps Editor due to a difference in the service @id in the Manifest and the @id in the info.json response.

Response	@id
Manifest	https://objects.library.uu.nl/fcgi-bin/iipsrv.fcgi?IIIF=/manifestation/viewer/67/63/67/6763679249338763006812240016163644362.jp2
info.json	http://objects.library.uu.nl/fcgi-bin/iipsrv.fcgi?IIIF=/manifestation/viewer/67/63/67/6763679249338763006812240016163644362.jp2

Solution

Change info.json @id to https://

[eduh]

About CORS: We implemented the CORS header in our IIPserver as documented in https://iipimage.sourceforge.io/documentation/server/ CORS (iipsrv-1.0 or later) Cross Origin Resource Sharing setting. Sets the Access-Control-Allow-Origin status on the server for AJAX requests. Use “*” for full public access or specify a particular IP address or domain. Not set by default. See the W3C specification or this tutorial for more details.

About the @id with http Looks like this is the out of the box behaviour of IIPImage which is hardcoded so I cannot change this. I will report this to the IIPImage developers.
But when I paste the json in the textbox and alter the @id to https it will not load either... Here is an example of our info.json { "@context" : "http://iiif.io/api/image/2/context.json", "@id" : "https://objects.library.uu.nl/fcgi-bin/iipsrv.fcgi?IIIF=/manifestation/viewer/56/84/75/56847504527355925228902123728198660686.jp2", "protocol" : "http://iiif.io/api/image", "width" : 2718, "height" : 3655, "sizes" : [ { "width" : 169, "height" : 228 }, { "width" : 339, "height" : 456 }, { "width" : 679, "height" : 913 }, { "width" : 1359, "height" : 1827 } ], "tiles" : [ { "width" : 256, "height" : 256, "scaleFactors" : [ 1, 2, 4, 8, 16 ] } ], "profile" : [ "http://iiif.io/api/image/2/level1.json", { "formats" : [ "jpg" ], "qualities" : [ "native","color","gray" ], "supports" : ["regionByPct","regionSquare","sizeByForcedWh","sizeByWh","sizeAboveFull","rotationBy90s","mirroring"] } ] }

I should state that when I load the image in https://editor.allmaps.org/ there is no problem

[sammeltassen]

Thanks for looking into it!

Yes the CORS issue seems to be resolved and the load problems I was still experiencing have to do with the http:// scheme as well. From the console in Chrome:

Mixed Content: The page at 'https://editor.allmaps.org/?#/collection?url=https%3A%2F%2Fobjects.library.uu.nl%2Ffcgi-bin%2Fiipsrv.fcgi%3FIIIF%3D%2Fmanifestation%2Fviewer%2F13%2F61%2F39%2F136139185182741493007400906779095484903.jp2%2Finfo.json&image=3727d41f361847a2' was loaded over HTTPS, but requested an insecure element 'http://objects.library.uu.nl/fcgi-bin/iipsrv.fcgi?IIIF=/manifestation/viewer/13/61/39/136139185182741493007400906779095484903.jp2/full/235,205/0/default.jpg'. This request was automatically upgraded to HTTPS, For more information see https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html

In Safari this means that the images are not loaded at all (it doesn't matter if you load the https:// url in the Allmaps Editor because it will still look up the @id property in the info.json and make the requests based on this URL). It's not possible to paste an info.json or manifest in the Allmaps Editor input box; the Allmaps Viewer currently only accepts georeferencing annotations.

Here's an example of an info.json served from the National Archives using https:// (they also use IIP server):

https://service.archief.nl/iipsrv?IIIF=/8c/7f/06/1e/58/55/40/56/87/96/4f/03/a7/19/fd/8e/593513c9-89a0-4163-b4ed-31d31ae61c5e.jp2/info.json

Maybe it's fixed in an update?

[eduh]

I have made a request to the IIPimage forum. Hope there is a solution for it. But...I noticed that that the National Archive url is not working. It throws an error. https://viewer.allmaps.org/?url=https%3A%2F%2Fservice.archief.nl%2Fiipsrv%3FIIIF%3D%2F8c%2F7f%2F06%2F1e%2F58%2F55%2F40%2F56%2F87%2F96%2F4f%2F03%2Fa7%2F19%2Ffd%2F8e%2F593513c9-89a0-4163-b4ed-31d31ae61c5e.jp2%2Finfo.json

[sammeltassen]

The place to try it is the Allmaps Editor, not the Viewer (which currently only accepts Georeferencing Annotations), i.e.: https://editor.allmaps.org/#/collection?url=https%3A%2F%2Fservice.archief.nl%2Fiipsrv%3FIIIF%3D%2F8c%2F7f%2F06%2F1e%2F58%2F55%2F40%2F56%2F87%2F96%2F4f%2F03%2Fa7%2F19%2Ffd%2F8e%2F593513c9-89a0-4163-b4ed-31d31ae61c5e.jp2%2Finfo.json&image=8e6e6b0e99e723c5

Here's the same map in the Allmaps Viewer: https://viewer.allmaps.org/?url=https%3A%2F%2Fannotations.allmaps.org%2Fimages%2F8e6e6b0e99e723c5

And the Georeferencing Annotation: https://annotations.allmaps.org/images/8e6e6b0e99e723c5

(The format of these annotations will change a bit according to the recently approved specifications: https://preview.iiif.io/api/georef/extension/georef/)

[eduh]

Ik heb in een testopstelling de BASE_URL setting van IIPImage aangepast naar https. Het lijkt nu te werken voor deze test https://editor.allmaps.org/?#/collection?url=https%3A%2F%2Fiiif.apps-dev.k8s.library.uu.nl%2Ffcgi-bin%2Fiipsrv.fcgi%3FIIIF%3D%2Fmanifestation%2Fviewer%2F12%2F34%2F75%2F123475797878481002619253132838342385263.jp2%2Finfo.json&image=339164dd72070633

Als achtergrond : wij hebben NGINX als reverse proxy draaien en die communiceert met de daadwerkelijke apache\fcgi site en die draait onder http dus dan worden de @id's ook http. Dit is gedaan omdat het alleen intern netwerkverkeer betreft en het kubernetes platform encrypt sowieso de traffic. Misschien kunnen jullie nog eens dubbelchecken? Als het werkt gaan we het in productie uitrollen. De clean url's wachten we nog even mee want dat heeft geen prio en raakt aan meerdere zaken bij ons.

[sammeltassen]

Dank. IDs zijn nu goed inderdaad!

Maar toch ontbreken de juiste response headers soms. Uit de Chrome console:

Access to image at 'https://iiif.apps-dev.k8s.library.uu.nl/fcgi-bin/iipsrv.fcgi?IIIF=/manifestation/viewer/12/34/75/123475797878481002619253132838342385263.jp2/full/596,/0/default.jpg' from origin 'https://viewer.allmaps.org' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Inderdaad ontbreekt de Access-Control-Allow-Origin header in de response voor dit beeld. Maar bij de request voor de volgende tile is deze header wel aanwezig:

https://iiif.apps-dev.k8s.library.uu.nl/fcgi-bin/iipsrv.fcgi?IIIF=/manifestation/viewer/12/34/75/123475797878481002619253132838342385263.jp2/0,1024,1024,1024/256,/0/default.jpg

Wat verklaart deze verschillende responses? Cache?

[eduh]

Heel bijzonder. In principe is er 1 setting voor de IIPImage cors header en deze zou voor alle tiles hetzelfde moeten werken. Ik kan het niet linken aan Cache oid maar ik sluit niets uit. Ik hoop dat we deze week in ieder geval de https fix voor de @id in productie te zetten. Dan kan ik daarna wat info opsturen naar Iipimage. Allerlei andere iiif apps\viewers hebben overigens geen problemen met de images en lijken goed te functioneren.

[eduh]

Ik heb met de IIPImage overlegd en ze hebben een bugje gevonden en nog mooier, direct opgelost. Zie https://github.com/ruven/iipsrv/issues/256 Blijkbaar vroegen jullie een region ipv tile en daar ontbrak de header. Ik zie nu beide url's goed gaan met een CORS header. NB: als het uit een browser cache komt dan zijn deze headers er uiteraard niet. Dus even refreshen als je het wilt checken. Deze is nu correct: https://iiif.apps-dev.k8s.library.uu.nl/fcgi-bin/iipsrv.fcgi?IIIF=/manifestation/viewer/12/34/75/123475797878481002619253132838342385263.jp2/full/256,/0/default.jpg Hopelijk gaan we snel met deze fix in productie.

[eduh]

Overigens....alle organisaties die IIPImage gebruiken zullen deze bug ook hebben bij deze url construct totdat ze het fixen.

[sammeltassen]

Wat goed! Hier inderdaad ook de goede headers. Dank wederom en we horen graag als het in productie is.

@bertspaan Zou dit ook de verschillende responses bij de Bibliothèque nationale de France kunnen verklaren?

[bertspaan]

@eduh! heel goed dat 't op deze manier opgelost is!

@sammeltassen: zou kunnen, maar volgens mij zijn 't daar allemaal tile urls. Althans, dat zou moeten. Misschien bereken ik de afmetingen van de tiles verkeerd. Of IIPImage doet dat verkeerd. Dit is hoe 't moet volgende de IIIF-spec: https://iiif.io/api/image/3.0/implementation/#3-tile-region-parameter-calculation. We moeten even twee URL's van de BNF verzamelen, 1 die het wél doet, 1 die het niet doet.

[sammeltassen]

@bertspaan Ja, ik maak een apart issue aan daarvoor

[bertspaan]

@sammeltassen dit issue kan dan gesloten worden, toch?

[sammeltassen]

Nog even wachten totdat het in productie is in Utrecht

[eduh]

yep, laat nog heel even open. Ik hoor net dat onze conservator Marco van Egmond 2 weekjes met vakantie gaat en die moet als stakeholder de testen goedkeuren voordat we het uitrollen.......

[eduh]

We zijn net in productie gegaan met IIIF. Een manifest direct benaderen kan via de url : https://objects.library.uu.nl/manifest/iiif/v2/1874-369423 Je kan ook naar een tussenpagina gaan met IIIF info : https://objects.library.uu.nl/reader/iiif_info.php?obj=1874-369423&pagenum=1&lan=en Hoop dat alles naar verwachting werkt.

[bertspaan]

Ik heb 't net getest, volgens mij werkt alles heel goed!

Voorbeeld:

• Manifest: https://objects.library.uu.nl/manifest/iiif/v2/1874-20407
• Allmaps Editor: https://editor.allmaps.org/?#/mask?url=https%3A%2F%2Fobjects.library.uu.nl%2Fmanifest%2Fiiif%2Fv2%2F1874-20407&image=8cc9233cbe56b307
• Resultaat: https://viewer.allmaps.org/?url=https%3A%2F%2Fannotations.allmaps.org%2Fmanifests%2Fe5aab9e9152b235b

[eduh]

Mooi, dan kan deze call gesloten worden wat mij betreft.

[sammeltassen]

@eduh Fantastisch dat het gelukt is!

Ik heb meteen dit afgemaakt om de kaarten te kunnen georefereren met Allmaps: https://observablehq.com/@allmaps/georeferencing-uu

De beelden bleken niet goed te laden in het component dat ik gebruik om een preview te geven van het manifest. Dit komt omdat de afmetingen van het canvas niet overeenkomen met de afmetingen van de painting annotation.

Bijvoorbeeld in: https://objects.library.uu.nl/manifest/iiif/v2/1874-349709 zijn de dimensies van het canvas:

"height": 6078,
"width": 4434,

En van de painting annotation:

"height": 5793,
"width": 7885,

Is er een verklaring voor dit verschil?

[eduh]

Ja, dat is te verklaren en wellicht een stukje documentatie van IIIF wat ik niet goed heb begrepen of waarschijnlijker....niet aandachtig genoeg heb gelezen. De 5793x7885 is de juiste waarde. Die 6078x4434 is een fictieve hardcoded waarde omdat ik dacht dat die niet van belang zou zijn.....wel dus. Dat moet ik dus herstellen maar dat gaat deze week denk ik niet lukken.

[eduh]

Zou je even kunnen checken op de testinstance of deze fix werkt voor jullie...zou ik het wellicht toch nog even kunnen doorzetten naar productie https://iiif.apps-dev.k8s.library.uu.nl/manifest/iiif/v2/1874-349709

[sammeltassen]

@eduh Dank voor de snelle fix, ik heb het getest en het werkt, ook voor manifesten bestaande uit canvassen met verschillende afmetingen!

[eduh]

De fix staat nu in productie. Zie https://objects.library.uu.nl/manifest/iiif/v2/1874-349709

[sammeltassen]

Dank wederom!