Access-Control-Expose-Headers: How to expose additional headers in spaces CDN?

In order to download files from DigitalOcean Spaces CDN using xhr, I need to add a following CORS header to OPTIONS/GET responses: Access-Control-Expose-Headers: ETag, Content-Range. If I don’t do that, I get a similar error in my google chrome console: Refused to get unsafe header "etag" (see

Spaces CDN settings make it possible to allow additional request headers (Access-Control-Allow-Headers), but there’s no option to expose additional headers (Access-Control-Expose-Headers).

Since I’m using CloudFlare for DNS management, I worked around this issue by deploying a web worker that adds Access-Control-Expose-Headers: ETag, Content-Range to every response from spaces CDN but ideally this would be possible in spaces settings.

Has anybody run into this issue? Do you know if they have plans to add this setting?

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.

Writing this in case it’s helpful for future readers:

I was struggling with a similar issue, where we used pre-signed URLs with the DigitalOcean spaces storage backend for multi-part file uploads.

Initially, the requests failed entirely due to lacking CORS policies in the DigitalOcean spaces responses. After some diggin, it turned out you can configure CORS policies in the DO spaces management dashboard.

Next issue we ran to is that the client (browser) didn’t have access to the ETag response header sent by DigitalOcean spaces, as it was lacking the Access-Control-Expose-Headers header allowing the access to the ETag header. To solve this, there doesn’t seem to be an official DigitalOcean supported way to do it, but luckily I found this thread which showed how you can do it directly with s3cmd:

With s3cmd, it’s possible to upload a CORS policy file directly to the bucket, which also works on DigitalOcean spaces. This overrides any existing CORS settings set on the bucket

Example CORS policy file:

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="">

Note how we can define the ExposeHeader property here on top of the settings already manageable on the DigitalOcean dashboard. I do not know why has the option been omitted from the official UI.

Once you have the file and s3cmd configured, it’s simple enough to upload to the bucket:

s3cmd setcors FILE s3://BUCKET