Fix endpoint detection logic, broken on FetchError

[0x2b3bfa0]

Detecting errors other than the vanilla Error isn't especially easy nor reliable, or so it seems. Given that we only return errors and strings, it's easier to consider as an error everything that isn't a string.

[0x2b3bfa0]

Spent 30+ minutes figuring out why this user was querying a project with a broken full address beginning with ttps instead of the usual user/project format.

It turns out that the projectPath function wasn't checking if repo.startsWith(repoBase) before running repo.replace(repoBase, '').substr(1) and it just worsened the issue by removing the first character without removing the expected prefix.

Are my deffensive programming instincts worth the time? At least in certain cases, these extra checks could be within reason.

[DavidGOrtega]

Not sure if this is solving the real issue. And of course nothing to be with the original case. The problem is that in CML.js we assume always https.

[0x2b3bfa0]

Not sure if this is solving the real issue.

This pull request just fixes a bug where every connection error gets masked under a barely meaningful TypeError: Only absolute URLs are supported error. Not sure if that's the real issue you mention, but at least it helps us to give unerring replies to users with real issues that are reporting the mentioned unhelpful error.

And of course nothing to be with the original case.

If you mean this Discord conversation, it would have been impossible to provide an accurate solution without the code from this pull request. 🤔

The problem is that in CML.js we assume always https.

That's a good default, but some self-hosted users might still be relying on bare HTTP. It looks like you've identified another potential issue.

[DavidGOrtega]

That's a good default, but some self-hosted users might still be relying on bare HTTP. It looks like you've identified another potential issue.

I think thats the real issue of your user.

All this pain could be solved checking http vs https since http wont even work either in any circumstance

[0x2b3bfa0]

I think thats the real issue of your user.

It looks like "my" user had a slightly more creative issue, where a plain HTTP server was listening on port 443 instead of 80.

All this pain could be solved checking http vs https since http wont even work either in any circumstance

How come? Moved to #616