Access-Control-Allow-Origin header

[MarcAgate]

Hi, we have both headers.add("Access-Control-Allow-Origin", "*") and response.setHeader("Access-Control-Allow-Origin", "*"); in IIIFImageApiController

However, we might want a different setting for that header or we might want to have it also for "{identifier}/{region}/{size}/{rotation}/{quality}.{format}" urls (this header is only set for redirect and info.json request types in the current implementation). I implemented a filter in order to solve this issue (that gets even more CORS headers values from application.yml file for setting them), but It resulted in a double "Access-Control-Allow-Origin" in the response since Filters are applied before the response is built.

I therefore ended up with a custom version of IIIFImageApiController in which the lines above are commented out. I think there should be a way to externalize CORS headers settings and other headers - for instance cache related headers - (eventually by using a filter as described above).

[jbaiter]

That is a good suggestion, would a headers section in the application.yml be enough for your purposes?

headers:
  image_api:
    all:
      # Headers common to all image endpoints
      access-control-allow-origin: *
    info:
      # info.json specific headers
      cache-control: max-age=86400
    image:
      # image specific headers
      cache-control: max-age=604800

[MarcAgate]

The issue is not really about HOW to set up CORS or cache headers values; it's about being free to set up or not any CORS or cache headers. While it makes sense to systematically -by default- set up "content-type" and eventually "Link" headers, it shouldn't be the case for all other optional headers.

An implementation like this one (https://github.com/BuddhistDigitalResourceCenter/buda-iiif-server/blob/master/src/main/java/de/digitalcollections/iiif/myhymir/HeaderFilter.java) should be possible without having to modifiy the IIIFImageApiController. Therefore, hymir server could have some defaut values for CORS and cache headers, but these wouldn't be applied directly in the Controller but outside of it through a basic filter mechanism that could be both optional (applyHeader: true in applictaion yml) and extendable (extends HymyrDefaultHeaderFilter).

We could also have some optional code (like we do for redirect) that uses a specific class that would apply default headers or custom headers (through the extension or implementation/overidding of this default class) - something like Headers.applyHeaders(boolean apply);

[eroux]

@jbaiter your proposal would work for us, ideally with the convention that a null value makes hymir not set the header (nor remove it), would that work for you?

[morpheus-87]

Will be possible with the upcoming release 4.0.0.