Calculer Girl
  1. Calculer Girl
  3. 404 Erreur lors de la tentative d’access à l’URL websocket sur WildFly sur le serveur, fonctionne parfaitement sur localhost
Intereting Posts
Soyez averti de la modification de l’interface réseau sous Linux Comment changer le texte et la couleur de fond? Comstackr un binary statique qui code là une fonction gethostbyname NPM ne peut pas installer les applications. Erreur: Impossible de trouver le module ‘graceful-fs’ Comment redirect une URL de requête complète avec une chaîne de requête échappée? Demander une page Web avec Cron Apache – comment faire des requêtes http sur https uniquement? Docker Composer avec PHP, MySQL, problème de connexion nginx Pourquoi certains liens pdf téléchargent-ils le fichier et d’autres le montrent-ils? Comment empêcher les fichiers créés avec GetTempFileName d’être automatiquement supprimés lors du redémarrage Comment puis-je suivre et rapporter intégralement une chaîne de liens symboliques? Apache proxyPassReverse et Websockets La performance de mongodb est-elle plus lente lorsque le stockage sur disque est presque plein Comment renvoyer une valeur à partir d’un script shell dans un script python Sémaphore sans destruction / cartographie de la condition de course

404 Erreur lors de la tentative d’access à l’URL websocket sur WildFly sur le serveur, fonctionne parfaitement sur localhost

J’ai créé et testé une application Java EE 7 qui utilise WebSockets sur mon PC local. Tout fonctionne bien lorsque je déploie sur WildFly 8 sur mon ordinateur local et accède à l’application à l’aide de localhost.

Lorsque je déploie la même application sur un serveur cloud (Ubuntu 14.04) avec exactement la même configuration WildFly, le message suivant s’affiche lorsque l’application tente de se connecter: 

"NetworkError: 404 Not Found - http://178.11.11.11:8080/pss/ws/notification" Firefox can't establish a connection to the server at ws://178.11.11.11:8080/pss/ws/notification.

Je peux accéder à l’application, c’est juste la connexion WebSocket qui échoue.

pss est ma racine de contexte, et le sharepoint terminaison websocket est annoté avec @ServerEndpoint (“/ ws / notification”), donc l’URL est correcte et fonctionne à 100% sur ma machine locale en utilisant localhost.

Lorsque je déploie l’application, je peux voir que le sharepoint terminaison websocket a été récupéré par WildFly, ce n’est donc pas le problème. 

 2015-02-14 14:18:21,200 INFO [io.undertow.websockets.jsr] (MSC service thread 1-2) UT026003: Adding annotated server endpoint class za.co.ssms.interfaces.websocket.NotificationWebSocket for path /ws/notification

Les en-têtes de requête sont corrects: 

 Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding gzip, deflate Accept-Language en-US,en;q=0.5 Cache-Control no-cache Connection keep-alive, Upgrade Cookie JSESSIONID=mgFhI1MAZwT2NwULXDXgEaXt.app Host 178.11.11.11:8080 Origin http://178.11.11.11:8080 Pragma no-cache Sec-WebSocket-Key LD55xYAKjJoXgLXQpUS7fA== Sec-WebSocket-Version 13 Upgrade websocket User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:35.0) Gecko/20100101 Firefox/35.0

J’accède à l’application en utilisant l’URL suivante (IP modifié), et les ports correspondent: 

 http://178.11.11.11:8080/pss/

Si je lance netstat -an | grep ‘LISTEN’ sur mon serveur cloud J’obtiens ce qui suit, qui montre que 0.0.0.0:8080 est lié et écoute: 

 tcp 0 0 127.0.0.1:9990 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:3528 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:8787 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp6 0 0 :::22 :::* LISTEN unix 2 [ ACC ] STREAM LISTENING 9227 /var/run/acpid.socket unix 2 [ ACC ] STREAM LISTENING 7014 @/com/ubuntu/upstart unix 2 [ ACC ] STREAM LISTENING 8907 /var/run/dbus/system_bus_socket unix 2 [ ACC ] STREAM LISTENING 9448 /var/run/mysqld/mysqld.sock unix 2 [ ACC ] SEQPACKET LISTENING 7666 /run/udev/control

Mon interface publique est configurée comme indiqué ci-dessous:

Apache n’est pas installé, il s’agit donc d’une connexion directe au serveur Wildfly.

Après plusieurs jours, je suis assez perplexe quant à la raison pour laquelle cela échoue.

Un organisme a-t-il déjà expérimenté cela et a-t-il une solution, ou avez-vous un moyen de résoudre ce problème plus avant?

Merci

J’ai eu des problèmes similaires.

mais toutes les demandes de mise à niveau http échouent avec un 404. Le même appel fonctionne lorsque WildFly et le navigateur sont sur le même ordinateur

La raison du travail n’est pas nécessairement due au fait d’avoir été sur la même machine, testé en se connectant à la machine d’un collègue sur le même réseau, la connexion fonctionnait.

Comment j’ai résolu mon problème:

J’ai fait un tcpdump sur le serveur et j’ai remarqué que l’en-tête http de la mise à niveau manquait au trafic, mais ce n’était pas le cas lorsque je me connectais via un autre réseau (modem de connexion de téléphone portable).

Mauvais vidage de connexion: 

 GET /websocket/api/alert HTTP/1.0 Host: www.example.co.za Pragma: no-cache Origin: http://www.example.co.za Sec-WebSocket-Version: 13 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Accept-Encoding: gzip, deflate, sdch Accept-Language: en-US,en;q=0.8 Cookie: JSESSIONID=biPOHuOQGRlw59eDqH4nevzt.mpilotech2 Sec-WebSocket-Key: U7f+gZQLqFLX18x6vB+i1Q== Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits Via: 1.1 localhost (squid/3.0.STABLE19) X-Forwarded-For: 10.1.1.148 Cache-Control: no-cache, max-age=259200 Connection: keep-alive HTTP/1.1 404 Not Found Server: nginx/1.8.0 Date: Wed, 06 May 2015 08:29:05 GMT Content-Length: 0 Connection: keep-alive Access-Control-Allow-Origin: http://www.example.co.za Vary: Origin X-Powered-By: Undertow/1 Access-Control-Allow-Credentials: true

Bon vidage de connexion: 

 GET /websocket/api/alert HTTP/1.1 Host: www.example.co.za Connection: Upgrade Pragma: no-cache Cache-Control: no-cache Upgrade: websocket Origin: http://www.example.co.za Sec-WebSocket-Version: 13 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Accept-Encoding: gzip, deflate, sdch Accept-Language: en-US,en;q=0.8 Cookie: JSESSIONID=biPOHuOQGRlw59eDqH4nevzt.mpilotech2 Sec-WebSocket-Key: xY36TVE76RzHujuFljtq/w== Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits HTTP/1.1 101 Switching Protocols Server: nginx/1.8.0 Date: Wed, 06 May 2015 08:31:19 GMT Content-Length: 0 Connection: upgrade X-Powered-By: Undertow/1 Origin: http://www.example.co.za Upgrade: WebSocket Sec-WebSocket-Accept: sxwgjN1BONLj5U5Kjh80fjQWBo4= Access-Control-Allow-Origin: http://www.example.co.za Vary: Origin Sec-WebSocket-Location: ws://127.0.0.1:8180/websocket/api/alert Access-Control-Allow-Credentials: true

Ensuite, j’ai remarqué que la connexion défaillante passe par un serveur proxy squid 3, la lecture sur le Web a révélé que le serveur proxy ne prend pas en charge Websocket.

Ma solution temporaire consistait à créer un certificate auto-signé et à passer à wss que je termine sur mon proxy inverse au lieu de ws pour la connexion.

Instructions pour la création du certificate: https://www.digitalocean.com/community/tutorials/how-to-create-an-ssl-certificatee-on-nginx-for-ubuntu-14-04

Vous n’avez pas à utiliser Ubuntu, j’utilise CentOS, la plupart des instructions sont toujours les mêmes.

J’espère que cela fera économiser quelques heures à quelqu’un