Tant mieux si ça vous débloque !

Je ne pourrais pas t'en dire plus au sujet des websockets, je sais en revanche que j'ai dû parfois ajouter des headers personnalisés pour faire fonctionner certaines redirections.
Et sur ce point très difficile de trouver des infos pour le proxy inversé de DSM contrairement à HAProxy ou Nginx.

Effectivement, ça refonctionne chez moi, nickel..
Merci bien Thierry94 pour le gros coup de pouce. Merci aussi à toi Shadowking pour l info.

Envoyé de mon téléphone en utilisant Tapatalk

Il y a 17 heures, Thierry94 a dit :

Question aux connaisseurs : a quoi correspond cette entête personnaliée ?

N’utilisant pas (encore) la vidéo-surveillance, j’étais passé à côté de ce souci avec DS cam.

Pour que les WebSockets fonctionnent sur un proxy inversé, il est impératif de déclarer explicitement les en-têtes nécessaires à l’établissement de la connexion.

La solution trouvée est très intéressante car elle montre que Synology a ENFIN compris que les WebSockets sont beaucoup plus efficaces pour le transport de flux continus que HTTP.

Je leur avais déjà adressé une demande d’evolution dans ce sens il y a 3 ans pour DSM où le polling HTTP plombe les performances des NAS (tout ce qui concerne la télémétrie comme le Moniteur de ressources, et toutes les actions de polling intensives). L’impact de l’utilisation des WebSockets dans DSM serait très bénéfique sur les performances, et particulièrement sur les modèles d’entrée de gamme.

On verra ce que ça donnera avec DSM 7 (même si je n’y crois pas vraiment).

Je ne connais rien aux websockets mais j'ai vu que sa mise en place dans le reverse proxy générait une ligne "$http_upgrade"
Ma question de néophyte : cela ne remet pas en cause la liaison https sur le port 443 entre l'équipement sur internet et le du reverse proxy du NAS ? 

Modifié le 21 août 20196 a par Thierry94

Non, ça n’en pose aucun problème. Si le client ne demande pas un WebSocket, l’en-tête est ignorée.

Si je te comprend bien cela veut dire que quand le client demande un websocket on passe alors en http ?

Dans notre cas le client est DScam, et visiblement il demande le websocket puisque sans l'entête personnalisée ça ne marche pas.
Alors problème ou pas avec le https du reverse proxy .. autrement dit à l'ouverture de l'appli lorsque le login et le mot de passe sont saisis il ne circuleront pas en clair sur le réseau ? 

WebSocket utilise le même chiffrement que la connexion HTTP avec laquelle il a été initialisé.

Bonjour,

 

Suite à investigation avec le support synology, il suffit de désactiver l'ipv6 dans les paramètres du ddns 🙂