doc: strange redirects

[jorgeorpinel]

One more for @iterative/websites 😬

Load any docs URL e.g. https://mlem.ai/doc and keep an eye in the address bar. A trailing / flashes really fast. Network activity:

A bit worrying that it's using 301s which browsers don't really ever want to forget from their caches so the least people get this the better.

Replicated in https://www.webpagetest.org/result/220524_BiDcB6_GK3/1/details/#waterfall_view_step1

[julieg18]

Weird! I wonder if has something to do with the fact that cml.dev and dvc.org are deployed with S3, while mlem.ai is just deployed with Heroku 🤔

[shcheklein]

@rogermparent should have more context on this - it's a combination of gatsby setup, redirects.json, and may be express that we are running.

[rogermparent]

mlem.ai currently isn't using Express, it's just heroku-buildpack-static with a plugin that generates a more standard redirects file based on Gatsby's createRedirect action (#66)

Based on that, there's only a few places the redirect could be coming from:

• we may have set up a CloudFlare page rule
• heroku-buildpack-static has been weirdly configured by us or by default

If I were to blindly guess I'd check CloudFlare first, but I don't have permissions there so someone who does will have to check in my place.

[rogermparent]

Now that I look at it again, this is doing the opposite of what we usually configure for (redirect from unslashed to slashed). That almost certainly rules out CloudFlare unless we grossly misconfigured it. In checking heroku-buildpack-static, I found this open issue which perfectly describes what's happening here-

1. navigate to https://doc/page
2. get redirected to http://doc/page/
3. get redirected to https://doc/page/
4. client-side URL change to https://doc/page (this one's our code, I think)

It seems like that issue nor this PR that seems to fix it has gotten any traction with the buildpack's maintainers, so unfortunately it seems the solution to this is to take it into our own hands and somehow switch away from heroku-buildpack-static, whether that be:

• another buildpack (theoretically we could fork heroku-buildpack-static and point to our fork directly on GH)
• an Express server (a little overkill with no APIs and we've discussed wanting to move away from requiring them, but I guess it does have consistency with our other sites as of now)
• a non-Heroku service like Gatsby Cloud

It's no secret that I'm a fan of the third option, but we can implement any of these to fix this issue.

[shcheklein]

@rogermparent thanks! can we make it consistent / same as dvc.org (and apply across all the websites for consistency)?

[rogermparent]

Sure! We were already thinking about adding an Express server so we can bump that up in priority with this issue in mind.