Probably if you dug deep enough, you'd get a sense of its internal logic, but I've been using nginx for years, roughly one hour every few months, and it always feels like I'm playing one of those war games that different rules subsections for every single possible situation.
I'm trying to save space on my VPS, so I've moved the contents of the
Hills bot to object storage. In order to proxy requests for Hills content to the VPS nginx server to the object storage, I do all this in the config:
# Put the slash on the ends of these bots that proxy to Spaces.
location ~ ^/bots/(hills)$ {
return 301 $request_uri/;
}
# Proxy / to /index.html. Unfortunate special case due to:
# https://www.digitalocean.com/community/questions/spaces-set-index-html-as-default-landing-page
# TODO: update (hills) to (hills|dem-bones|etc)
location ~ ^/bots/(hills)/$ {
#proxy_pass https://jimkang.com/index.html;
proxy_pass https://smidgeo.nyc3.digitaloceanspaces.com/bots/$1/index.html;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_cache_bypass $http_upgrade;
access_log /var/log/nginx/proxy-upstream-smallcatlabs-bots-access.log upstreamlog;
error_log /var/log/nginx/proxy-upstream-smallcatlabs-bots-error.log warn;
}
# General case for proxying spaces.
location ~ ^/bots/(hills)/.+ {
proxy_pass https://smidgeo.nyc3.digitaloceanspaces.com$request_uri;
# Turns out the SSL stuff is not actually necessary for proxying to https.
#proxy_ssl_certificate /etc/letsencrypt/live/smidgeo.com/cert.pem;
#proxy_ssl_certificate_key /etc/letsencrypt/live/smidgeo.com/privkey.pem;
#proxy_ssl_session_reuse on;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
# DO NOT SET HOST when proxying to Spaces. It uses this for the bucket name and will tell requesters "no such bucket".
#proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
access_log /var/log/nginx/proxy-upstream-smallcatlabs-bots-access.log upstreamlog;
error_log /var/log/nginx/proxy-upstream-smallcatlabs-bots-error.log warn;
}That is just so much! But that's what I need to properly handle requests for bots/hills, bots/hills/ and bots/hills/whatever.html, given that Digital Ocean Spaces won't redirect from / to index.html. nginx is opaque enough that I'm afraid to refactor once something's working.
Speaking of that missing Digital Ocean feature, sometimes, there's
quite a story in a set of comments.The original response to the feature request at the end of 2017:
We don’t support this in Spaces now (/ –> index.html) but are working on this now. Hope to have some good news for you early next year :) Thanks for the question.
Same guy, four months later:
We are still hoping to deliver this kind of functionality before end of year. Sorry I don’t have better / more news at this point.
Another user eight months after that:
It’s the end of the year, any updates?
Six months later, the PM chimes in:
Hi All - I am the PM for Spaces. We launched custom subdomain in April as a first step in providing a simple static sites hosting solution. This is currently in design and is the next thing we are working. As someone noted above it’s the last thing that’s required to complete the static hosting story.
Another half a year, in 2020:
Hello there DO from 2020, kinda started using spaces hoping this will be done before we are about to release…… we are way far from releasing our product but should we… look forward to this?.... :pray:
And then just a few days ago:
5 Quarters later it seems still not implemented.
Did you even try? Is it an abandoned idea?
Good to know before wasting time trying to use spaces as an S3 alternative.
I have seen this happen at many companies I've worked at. It's usually a failing of organizational structure and/or decision-making rules, e.g. not wanting to look like you're not throwing 100% into whatever the current OKRs are, despite there being relatively simple things you could do to make users happy.
