web-dev-qa-db-fra.com

Websockets non connectés derrière le proxy

C'est un problème assez courant, mais je ne trouve pas de solution à mon cas spécifique. J'utilise Glassfish 4.1.1 et mon application implémente des Websockets.

Côté client, je me connecte au serveur WS simplement en:

var serviceLocation = "ws://" + window.location.Host + window.location.pathname + "dialog/";
var wsocket = new WebSocket(serviceLocation + token_var);

Côté serveur, les Websockets sont implémentées via la fonctionnalité @ServerEndpoint et semblent très courantes:

@ServerEndpoint(value = "/dialog/{token}", decoders = DialogMessageDecoder.class)
public class DialogWebsoketEndpoint {

    @OnOpen
    public void open(final Session session, @PathParam("token") final String token) { ... }
etc.
}

Tout fonctionne bien jusqu'au moment où le client essaie de se connecter derrière le proxy. En utilisant ce test: http://websocketstest.com/ J'ai trouvé que l'ordinateur du client fonctionne derrière http-proxy 1.1. Il ne peut pas se connecter aux websockets, onopen ne se déclenche tout simplement pas. wsoscket.readyState ne devient jamais 1.

Comment puis-je régler mon ServerEndpoint pour faire fonctionner ce code même lorsque le client se connecte derrière un proxy?

Merci d'avance!

MISE À JOUR: Je fournirais une capture d'écran avec websocketstest sur cet ordinateur: enter image description here

Sur mon ordinateur, cela semble pareil sauf une chose: Proxy HTTP: NON.

javascriptjavaproxywebsocketglassfish
11
Luxor

Tout comme l'indiquent les commentaires des questions, il semble que le proxy ne prend pas correctement en charge les Websockets.

Il s'agit d'un problème courant (certaines sociétés de téléphonie mobile ont des serveurs proxy qui perturbent les connexions Websocket) et la solution consiste à utiliser des connexions TLS/SSL.

Le problème survient principalement parce que certains mandataires "corrigent" (lire: corrompus) les en-têtes de demande Websocket.

Cependant, lors de l'utilisation de TLS/SSL, les mandataires ne peuvent pas lire les données d'en-tête (qui sont chiffrées), ce qui provoque un "transfert" des données sur la plupart des mandataires.

Cela signifie que les en-têtes arriveront en toute sécurité à l'autre extrémité et que le proxy ignorera (la plupart du temps) la connexion ... cela peut toujours provoquer un problème concernant les délais de connexion, mais cela résout généralement le problème.

MODIFIER

Notez que les navigateurs protégeront le client contre le mélange de contenu non crypté avec du contenu crypté. Assurez-vous que le script lance les connexions ws en utilisant la variante wss lorsque des connexions TLS/SSL sont utilisées.

18
Myst