static proxy incorrectly redirecting, but not always

I’m using the static proxy feature to serve my web site:

[[statics]]
  guest_path = "/static/history"
  url_prefix = "/history"

[[statics]]
  guest_path = "/static"
  url_prefix = "/"

[[statics]]
  guest_path = "/static/services"
  url_prefix = "/services"

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?

Thanks.

Are any of these paths symlinks in your container?

No, they’re all ordinary files and directories. (I’m relying on the standard model that index.html is substituted for directory names.)

Following up privately. :slight_smile:

Will report back here if I get to the bottom of it.

I had a similar issue where sub paths weren’t being served. I disabled the static handler, but I’ll re-enable it to see if I still have this issue.

Any news on what might be going on here? I’m excited to move forward, and it really would be cool to use Fly’s equivalent of a CDN.

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.

Is rendering index.html when a path is accessed a new/confirmed feature?

Is rendering index.html when a path is accessed a new/confirmed feature?

It’s used in the basic fly.io example explaining how to set up a static web site.

Yeah, think it’s implicit, just wanted to confirm that for root and any subfolder in statics, the logic is:

  1. see if /abc/cdf is a file
  2. if not, check if /abc/cdf/ is a folder and has an index.html in it
  3. if not, fall through to the application

@thomas, that’s excellent news. Thank you very much.

Redirecting /foo/bar to /foo/bar/ is great. I’m in favor of automatic canonicalization like that.

Will you send a follow-up once the fix is deployed?

Thanks again.

I decided to try redeploying using just fly deploy. Alas, I get “Error An unknown error occured.” [sic] Here’s the tail of the transcript:

--> Building image done
==> Pushing image to fly
The push refers to repository [registry.fly.io/wild-thunder-4544]







deployment-1634160817: digest: sha256:9fd57d591dfe63503984bc4568111dc4336af36843d64da89b370bea3ca8152c size: 1780
--> Pushing image done
Image: registry.fly.io/wild-thunder-4544:deployment-1634160817
Image size: 96 MB
==> Creating release

Error An unknown error occured.

>

Just FYI, Kurt confirmed this is a new issue and they’re rolling back: Unable to deploy - #2 by kurt

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.