Websocket protocol - think about allow back compatibility.

[timbl]

A protocol should be defined to be be clear and complete and provide for a given functionality and also to have compatibility with old versions. Otherwise what is the point of a version string looking like 0.1.0-alpha?

The current rules are "server says protocol solid/0.1.0-alpha and the client if it receives anything else it should fail. If that is what you want.

Suggest alternative:

The version number produced by the server is n.m initially 1.0 . There is no alpha as that has no meaning. Future versions of the proctor are designed so that a client written to n.m can happily use a server of n.m2 where m2 > m . Future designers of the protocol commit that while by doing so, clients will be able to use all the functionality they have had before with servers running n.m though possibly missing out new features they don't know about.

Clients must not use a server of protocol version n2.m2 where n2 > m2. They return an error.

Clients typically CAN use a protocol n2.m where n2 < n because they have the old protocol built in. They don't have to support it but it is a good idea - unless there are security problems with it.

Maybe it is useful for the server to be able to offer more than one protocol.

Suggest the name of the protocol be solidpubsub rather than solid .

Putting things like 'warning Unstandardized protocol version, proceed with care' into the proctol or anywhere will prevent you from upgrading to a non-alpha protocol. Suggest the concept of alpha, like the X- concept, is not useful in protocols.

[Ryuno-Ki]

If I understand you correctly, this would imply an infinitive backwards compatibility in an ideal world?

Clients typically CAN use a protocol n2.m where n2 < n because they have the old protocol built in. They don't have to support it but it is a good idea

[RubenVerborgh]

Action suggested by @timbl during https://www.w3.org/community/solid/wiki/Meetings#2020-04-24_1600CET:

• make it v0.1
• drop the warning
• indicate that v1 will not be backwards compatible for security reasons

[scenaristeur]

Hi @ewingson setup Node Solid server on solidweb.org but it seems that it does not take in account wss protocol nor switch to wss , any idea ? https://gitlab.com/solidweb.org/support/-/issues/4

[bourgeoa]

@scenaristeur solidweb.org uses.NSS 5.6.0 while solidcommunity.net stayed on NSS 5.5.3

Could you check the test version on solidcommunity.net:8443 which is running a newer version not validated.

[scenaristeur]

as reported at https://gitlab.com/solidweb.org/support/-/issues/4#note_476693128 the problem is not new on solidweb.org but i did not take the time to report.
no problem on solidcommunity.net:8443 updated https://gitlab.com/solidweb.org/support/-/issues/4#note_476693128

I was waiting, hoping an update could solve the problem, but it never does. it does not seem to come from NSS, but more hosting or nginx config

[ewingson]

this part of the issue seemed to be hosting-specific.
modifying /etc/nginx/sites-available/default

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

enabled wss:// and solved it