As part of my divestiture from GoDaddy hosting for boyet.com, I had to move my old static site as well as this blog. The static site moved to secondboyet.com (being the second wave of blogging I did for boyet) and the third current wave is still on boyet.com (but now resides on Microsoft Azure). Because that second wave served up static pages (there ain’t no blog engine there) and because Amazon’s AWS is dirt cheap in those circumstances (plus it can serve it up securely via HTTPS and SSL), that’s where I moved it. I added a bit of code to boyet.com’s web.config to redirect requests and all was good.
Except when it wasn’t.
You see, although the site worked just dandily, it turned out that many links from Google results would point to the lowercase version of URLs rather than the mixed case I’d set up the site with originally. For example, the page I have there on the plays I’ve been involved with (either as actor or director) is at https://secondboyet.com/Articles/GeneralBook/Acting.html. Fair enough, however I was seeing requests to https://secondboyet.com/articles/generalbook/acting.html instead and they were failing. My 404 page for secondboyet was being triggered quite a bit.
You see, AWS – or rather S3, the cloud storage from Amazon where the pages are stored – is case-sensitive. To AWS/S3, those two URLs are completely different. To one who’s been dragged up through the whole DOS/Windows/Azure world where file names are case-insensitive – uppercase, lowercase, who cares? – it was a bit of a shock.
I pondered about what to do. Googling some terms to try and see some reasoning behind the resulting links didn’t reveal anything. Sometimes they were in uppercase (as I’d originally written them), sometimes not. I considered writing some kind of URL rewriting code to always convert to lowercase before allowing the request to proceed, and then converting all the filenames in my S3 bucket to lowercase. Yuk, these are 10-year-old posts, the number of times they come up in results is really small by now, so doing a lot of coding effort to try and get around this corner case just didn’t sound attractive.
And that suddenly made me smack myself upside the head. Since S3 is case-sensitive, I can just replicate the whole folder structure with lowercase names. Some people will get content via the case-insensitive filename, and some via the lowercase filename. They won’t know, but it’ll suddenly work again.
So, that’s what I did. The extra storage cost is virtually zero, and since I don’t change the site, I’ll have no further work to do. Yay! 
Loading links to posts on similar topics...
2 Responses
#1 Rob Chadwick said...
10-Dec-21 5:04 PMSmacking my forehead on this one. Our SEO and external links would be killed if we had to deal with case sensitivity. Your solution would be good for all upper/lower case, but mixed case? ugh.
There must be a better way?? All I can think of is iis mappings but serving files through my own server sort of defeats the purpose of a content delivery network.
#2 julian m bucknall said...
10-Dec-21 6:53 PM@Rob: Mea culpa in a sense. I'd changed the way I'd dealt with this problem, first with a Lambda@Edge function, which I then converted to a CloudFront function once that became available. Here's a continuation blog post: Case-sensitivity on AWS – redux.
Leave a response
Note: some MarkDown is allowed, but HTML is not. Expand to show what's available.
_emphasis_**strong**[text](url)`IEnumerable`* an item1. an item> Now is the time...Preview of response