I originally thought I only needed the second clause, and that recursion would take care of the rest. However, neither /history nor /services was served, so I added the first and third clause. Still, whenever I visit /history or /services, I’m redirected to /. Except when I’m not. I’ve found that if I wait long enough, /history will start to work, i.e. the file /static/history/index.html will be served there, and the images that it refers to will, too, even if I’ve left the deployed app untouched — if I haven’t even redeployed it. At the same time, /services will still get a 301 redirect to /.
Is there some cache invalidation magic that needs doing, or am I missing something obvious?
Sorry, I followed up privately (but somewhat vaguely).
You ran across a bug in our static asset handler stuff, relating to how we’re sanitizing paths. The fix is built and should be deployed within the next N hours (“hours not days”).
For what it’s worth: /foo/bar will redirect to /foo/bar/, and /foo/bar/ will render index.html in that directory.
The fix should be deployed to all our fly-proxies now. This would have happened earlier, but, see the community front page about the day we had. Sorry about that; this is truly a star-crossed bug Arthur found.