Discussion :

[Squalthor]

Bonjour,

Je travaille actuellement sur un serveur utilisant les websockets, j'utilise l'extension firefox/iceweasel firebug pour développer.
Lorsque la connexion websocket se coupe firebug me communique cette erreur (j'ai caché les chemins):

La connexion avec ws://"serveur:port" a été interrompue pendant le chargement de la page.
http://"serveur"/"script_js".js

J'aime pas, ça fait pas propre de voir cette "erreur" js dans firebug !
J'utilise "ws.onclose" pour la gérer mais firebug me la reconnait quand même.
Existe-t-il un moyen pour éviter/gérer cette erreur, qui au final n'en est pas vraiment une ?

Je vous remercie.

Cordialement, Squal.

[Golgotha]

Bonjour,

Une connexion websocket n'est pas sensé se couper

Donc je dirais que si la connexion est coupée c'est obligatoirement une erreur et donc le "a été interrompue" ne me choque pas du tout.

[Squalthor]

Bonjour Golgotha,

Merci pour ta participation.
Ne serait-ce pourtant pas tout simplement un evenement ? Le debuggeur de Chrome ne reconnait pourtant pas la rupture de la connexion comme une erreur.
De plus cette erreur survient même quand on actualise la page.

J'ai bien été tenté de camoufler l'erreur mais comme je me sert du code d'erreur pour adapter le messge de rupture de connexion je ne peut pas.

A mon avis je vais devoir laisser ainsi, mais ça m'embête...

Cordialement, Squal

[Golgotha]

Le principe du websocket si j'ai bien compris c'est d'avoir un tuyau ouvert en permanence (long pooling) entre le serveur et le/les client(s), ainsi, le serveur peux continuer d'envoyer des infos via ce tuyau. C'est presque contre nature ^^ puisque le HTML n'est pas pensé initialement pour faire ça.

Donc pour moi, oui c'est évènementiel, mais la connexion doit rester ouverte pour permettre au serveur de t'envoyer les évènements.

[Squalthor]

J'avoue ne pas comprendre totalement la logique, c'est peut-être parce que le principe html / websocket, et le fait que je ne sois pas coutumier de cette vue, me fausse le raisonnement...

Si on veux échanger la connexion websocket avec plusieurs serveusr (ce que je ne veux pas faire actuellement, mais qui serait logique avec une grosse appli) je peux le faire sans déconnecter le canal établi ?

[Bovino]

Non... WebSocket et long polling, ce n'est pas tout à fait la même chose.

Les WebSocket permettent au serveur d'envoyer à son initiative des informations au navigateur. La communication entre les deux n'est donc pas permanente mais ouverte uniquement en cas de besoin.
Le long polling est une solution alternative (pour les navigateurs n'implémentant pas les WebSocket) qui consiste à lancer une requête AJAX qui appelle un script dont on ne sait pas quand il renverra une réponse et on relance la requête chaque fois que la précédente se termine (réception d'une réponse ou timeout).

@Squalthor : je comprends pas trop ton problème...
Le rôle d'une console d'erreurs, c'est d'afficher les erreurs. Si tu ne veux pas les voir, désactive Firebug. En tout cas, il ne me semble pas que tu puisses choisir les erreurs qui te plaisent ou non.

[Squalthor]

Bonjour Bovino,

Et bien mon problème est simple en fait. En cas de plantage serveur j'ai inclus un settimeout dans mon fichier js pour rétablir la connexion dès que possible, la tentative de reconnexion se faisant toutes les 5 secondes.
A chaque connexion échouée j'ai une erreur javascript dans firebug.

Me donnant du mal pour n'avoir strictement aucune erreur, aussi bien css, html ou javascript, ça m'orripile... Surtout que dans ma logique la connexion échouée, ou stoppée n'est qu'un évenement, pas une erreur.

De plus le débuggeur de chrome lui ne reconnait pas cet évenement comme une erreur.

[Bovino]

Il faut bien comprendre que cette technologie est encore expérimentale, donc chaque navigateur implémente sa propre version.

Pour Firefox, tu devrais utiliser plutôt CloseEvent que la méthode que tu as mise en place...

[Golgotha]

@Bovino, oui, le websocket c'est l'officialisation et la normalisation du long pooling (je pense pas que techniquement, ça soit super différent.)

[Kaamo]

Même avec un onclose et ta propre gestion d'erreur à l'intérieur de celui-ci, il n'est pas possible, du moins à l'heure actuelle, d'empêcher ça. C'est horripilant mais c'est comme ça Le message sera toujours là indépendamment de ton code. J'a icru voir un bug ouvert chez eux, je ne le retrouve pas.

Ce message apparait quand le serveur se coupe bien sûr, et sous firefox : quand tu actualises ou appuies sur "Echap" !

Ça me fait penser à un problème que j'ai eu sur Firefox :

Si tu fais un "Echap" sur la page, Firefox interprète ça comme un arrêt de chargement de la page et .... des websockets / objets XHR. C'est normal que ce comportement opère quand la page est entrain de charger, mais même quand celle-ci est complétement chargée, le fait d'appuyer sur "Echap" coupe quand même la liaison ! Cela ne devrait pas

Du coup, j'ai bidouillé un ptit truc perso de mon côté qui permet de ne pas fermer les connexions socket quand la page a terminé de se charger. C'est moche, mais ça marche bien.

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
if (document.readyState === "complete"){
  window.addEventListener('keydown', function(e) {
    if (e.keyCode == 27)
      e.preventDefault();
  })
}

La même en jquery :

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
$(document).ready(function(){
  $(this).keypress(function(e){
    if(e.keyCode == 27)
      return false;
  });
});

la correction de ce comportement (ne pas arrêter les XHR et WS quand la page a fini de charger) est prévue pour Firefox 20. Espérons qu'ils en profitent pour retirer ce genre de message quand on a défini un gestionnaire d'erreur

[Squalthor]

Bonsoir Kaamo,

Super je te remercie ! Je n'avais pas vu ça et du coup tu m'évites une belle prise de tête...
Je pense que Firefox va sûrement règler ça, donc en attendant je laisse comme ça.

Juste pour savoir si ma logique est bonne: une interruption est un évenement non, donc le fait que ça ressorte en erreur n'est donc pas adéquate ?

Merci.

Cordialement, Squal.