proxied via https support

[tkurki]

Apparently the protocol is hard coded to ws - should take into account also the protocol where it was loaded from.

[panaaj]

Not sure to what scenario you are referring to which this happens. All connections (api or stream) are based on the received endpoints from the hello message from the server. I cannot replicate a situation where https or wss is not used if the endpoints define it.

If you could let me know how you get the issue to appear I will try to replicate it.

[tkurki]

Oh right. My setup is with balena.io, that provides a publicly accessible proxied https connection to the http server running on the RPi. The server does not know that it is proxied via https and nor should it, because that would break local use.

What if freeboard tried to simply fall back to the host it was loaded from with no discovery if discovery fails?

[panaaj]

So something like.... Send request to protocol://host:port/signalk If hello response received then use it else if (no response || response does not contain endpoints: { v1: { signalk-http: {}, signalk-ws: {} } then fall back to

{ 
   endpoints: { 
      v1: {
         signalk-http= "protocol://host:port/signalk/v1/api/",
         signalk-ws= "protocol://host:port/signalk/v1/stream",
      }
   }
}

The only issue I see is that currently, due to the differences in behaviour between node server and artemis, resource PUTs and installed apps list rely on being able to determine the server type from the hello response. Using a fallback will not guaraantee the correct server type so the above functions may not operate correctly.

Can we accelerate the PR's that seek to align server operation?

[panaaj]

Addressed in v2.0.0

[panaaj]

V2.0.0 released.