CORS error for OLS api

[oeway]

We are using the ols api to find tags for annotation our datasets at https://shareloc.xyz
It was working perfectly before, but recently, the it give us the CORS error:

Access to fetch at 'https://www.ebi.ac.uk/ols/api/suggest?q=s' from origin 'https://shareloc.xyz' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.Understand this errorAI

To reproduce, you can run the following js in any of the website, including localhost:

async function getCompletion(text: string) {
  const url = `https://www.ebi.ac.uk/ols/api/suggest?q=${text}`;
  let response = await fetch(url);
  if (response.ok) {
    const ret = await response.json();
    let results: string[] = [];
    if (ret.response.numFound > 0) {
      results = ret.response.docs.map((d: any) => d.autosuggest);
    }
    const selectUrl = `https://www.ebi.ac.uk/ols/api/select?q=${text}`;
    response = await fetch(selectUrl);
    if (response.ok) {
      const ret = await response.json();
      if (ret.response.numFound > 0) {
        results = results.concat(ret.response.docs.map((d: any) => d.label));
      }
    }
    results = results.filter((item, pos) => results.indexOf(item) === pos);
    return results;
  } else {
    console.error(`Failed to fetch completion from EBI OLS: ${url}`, response);
    return [];
  }
}

[haideriqbal]

@oeway thanks for reporting this... we are always adding CORS headers to our calls so it weird that this error is coming. We don't have any restriction on ORIGIN either...

// Alwasy add CORS headers. add CORS "pre-flight" request headers
        httpResponse.addHeader("Access-Control-Allow-Origin", "*");
        httpResponse.addHeader("Access-Control-Allow-Headers", "*");
        httpResponse.addHeader("Access-Control-Allow-Methods", "GET");
        httpResponse.addHeader("Access-Control-Max-Age", "3600");

I'll need to investigate this further on my end and for now my hunch is because of the redirection happening from /ols to /ols4 and somehow CORS headers are not added to the redirection. See my curl examples below:

With endpoint for ols4 we have origin headers:

curl -X OPTIONS "https://www.ebi.ac.uk/ols4/api/suggest?q=s" \
  -H "Origin: https://shareloc.xyz" \
  -H "Access-Control-Request-Method: GET" \
  -H "Access-Control-Request-Headers: Content-Type" \
  -v
> OPTIONS /ols4/api/suggest?q=s HTTP/1.1
> Host: www.ebi.ac.uk
> User-Agent: curl/8.5.0
> Accept: */*
> Origin: https://shareloc.xyz
> Access-Control-Request-Method: GET
> Access-Control-Request-Headers: Content-Type
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/1.1 200 
< Vary: Origin
< Vary: Access-Control-Request-Method
< Vary: Access-Control-Request-Headers
< Strict-Transport-Security: max-age=0
< Access-Control-Max-Age: 3600
< Date: Wed, 26 Feb 2025 22:12:46 GMT
< Access-Control-Allow-Origin: *
< Allow: GET, HEAD, POST, PUT, DELETE, OPTIONS, PATCH
< Access-Control-Allow-Headers: *
< Access-Control-Allow-Methods: GET
< Content-Length: 0
< 
* Connection #0 to host www.ebi.ac.uk left intact

But for ols endpoint they don't

> OPTIONS /ols/api/suggest?q=s HTTP/1.1
> Host: www.ebi.ac.uk
> User-Agent: curl/8.5.0
> Accept: */*
> Origin: https://shareloc.xyz
> Access-Control-Request-Method: GET
> Access-Control-Request-Headers: Content-Type
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/1.1 301 Moved Permanently
< Content-Type: text/html
< Date: Wed, 26 Feb 2025 22:14:23 GMT
< Location: https://www.ebi.ac.uk/ols4/api/suggest?q=s
< Connection: Keep-Alive
< Content-Length: 0
< 
* Connection #0 to host www.ebi.ac.uk left intact

The quickest solution for you atm I would suggest is to use https://www.ebi.ac.uk/ols4/api/suggest?q=${text} but will investigate on our end to how we can solve this for original ols endpoint as well.