Une interface en https ne propose plus une WebSocket en clair
Qui saisit « https://kastell.exemple.org » comme adresse publique se voyait proposer « ws:// » pour le serveur média, puis avertir trois lignes plus bas que son navigateur refuserait cette adresse. Le script fabriquait l'erreur qu'il annonçait. La mutualisation avait le défaut inverse et plus discret : elle proposait « wss:// » quoi qu'il arrive, y compris derrière une interface en clair, où il n'y a ni certificat ni raison d'en vouloir un. Les deux voies déduisent maintenant le schéma de celui de l'interface, qui était déjà connu — schema_public servait à l'avertissement, il sert désormais aussi au défaut. L'avertissement gagne son pendant Défaut « wss:// » et silence auraient laissé croire que le TLS vient tout seul. Il ne vient pas : LiveKit écoute en clair, et « wss:// » ne répond que s'il y a un proxy et un certificat devant ce port. Le script le dit maintenant quand l'adresse est en wss:// et que le serveur est celui de la composition — le cas où l'exploitant est responsable de cette terminaison. L'avertissement de contenu mixte reste, pour qui force « ws:// » malgré tout. Les deux ne se déclenchent jamais ensemble. Contrôlé https donne wss:// et l'avertissement de terminaison TLS ; http donne ws:// et rien ; la mutualisation suit les deux ; et « ws:// » saisi à la main derrière une interface https déclenche toujours l'avertissement de contenu mixte. Co-Authored-By:Claude Opus 5 <noreply@anthropic.com>