Failure to load IIIF manifest from URL in updated-iiii-demo branch

[vincentmarchetti]

The website viewer at https://blacklodge.hki.uni-koeln.de/viewer is not loading IIIF manifests directly from the manifest URL, but does work with the manifest text encodided in a data sheme URL; I see the same behavior working with a webpage served up with local copy of the code in the updated-iiif-demo branch.

In network console, working with a manifest on Amazon S3, at https://spri-open-resources.s3.us-east-2.amazonaws.com/Leeds2025Demo/astronaut_saxaphone_no_camera.json , I see a type 403 error on the fetch for the manifest, associated with CORS restriction. However this URL is loaded by other manifest viewers as well as passing CORS tests.

It looks like the 403 status code is being returned by the HTTP OPTIONS preflight call made by the kompakkt viewer; and that OPTIONS call is being made because of the way the fetch call is invoked in the processing.service.ts file at line 376.

Making the code patch as described:

--- a/src/app/services/processing/processing.service.ts
+++ b/src/app/services/processing/processing.service.ts
@@ -373,12 +373,7 @@ export class ProcessingService {
   }
 
   private async loadIIIF3DManifest(manifestUrl: string) {
-    const manifestJson = await fetch(decodeURIUntilStable(manifestUrl), {
-      method: 'GET',
-      headers: {
-        'Content-Type': 'application/json',
-      },
-    })
+    const manifestJson = await fetch(decodeURIUntilStable(manifestUrl), {})
       .then(res => res.json() as object)
       .catch(error => {
         console.log('Error loading manifest:', error);

in my local copy did allow the page to directly load the manifest, at least for these two test cases, on two different servers:

http://localhost:4200/?locale=en&standalone=true&manifest=https://spri-open-resources.s3.us-east-2.amazonaws.com/Leeds2025Demo/astronaut_saxaphone_no_camera.json

http://localhost:4200/?locale=en&standalone=true&manifest=https://gautschr.github.io/3D-modelling/iiif-manifests/poolcomplex/pool.json

I did not submit this as a pull request because the patch could be regarded as a circumvention of the CORS specs, as I understand them as described at

CORS
preflight request

and the correct solution would be for the servers to accept the pre-flight request. So this is submitted as a possible explanation for the behavior of the page.