I was trying to set up a Spaces CDN for my Spaces bucket and after some headache regarding the subdirectory path, SSL, and precompile, I got it working, sort of. All the assets load correctly but nothing is executing. Based on Digitalocean block storage VS amazon S3 - #5 by md-misko, it seems like the content-encoding header is stripped, which is breaking things.
Can anyone confirm if this is the source of the problem and that it remains an open bug with DO?
Has anyone found a workaround to this? A free CDN would be a massive cost savings.
Personally, I think I would love to see additional details in the Using Object Storage for Uploads (S3 & Clones) post, maybe even a DO open issue, so that I could confirm the issue and that it was still up to date info.
Maybe that’s just the part of me that wants to confirm everything myself
The doc at Using Object Storage for Uploads (S3 & Clones) is a wiki. We are collaboratively documenting how various CDNs work. I don’t use DigitalOcean’s object storage, so I can’t provide anymore details. Perhaps you could?
That’s a great suggestion, I like to provide a link to allow users of a service to lend their voice to prioritize fixes. I did some searching and couldn’t find a specific issue about DO’s CDN, but I found several spread all over the place. Which one do we link to? As a user of the service, our community relies on contributors like you to check out those details.
I’m a novice with sysadmin/cloud stuff, so hopefully someone can double check me before I make any edits.
These are the missing headers I see in non-CDN /assets but missing in CDN /assets:
content-encoding
expires (though there’s x-amz-expiration)
server
X-Firefox-Spdy
When I compare to meta.discourse.org’s cloudfront CDN /assets headers, they’re missing expires (and x-amz-expiration), but have all the other headers compared to non-CDN /assets.
Which one do we link to? As a user of the service, our community relies on contributors like you to check out those details. 