Websockets não ligados por detrás do 'proxy'

Este é um problema bastante comum, mas não consigo encontrar uma solução para o meu caso específico. Estou a usar o Glassfish 4.1.1 e o meu aplicativo implementa WebSocket.

do lado do cliente, estou a ligar-me ao ws-server simplesmente por:

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

num servidor, os websockets são implementados através da funcionalidade @ServerEndpoint e parece muito comum:

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

    @OnOpen
    public void open(final Session session, @PathParam("token") final String token) { ... }
etc.
}
Tudo funciona bem até ao momento em que o cliente tenta ligar-se atrás do proxy. Utilizar este teste: http://websocketstest.com/ descobri que o computador do cliente trabalha por trás do http-proxy 1.1. Ele não pode se conectar a websockets, onopen simplesmente não disparar em tudo. wsoscket.readyState nunca se torna 1.

Como posso sintonizar o meu ServerEndpoint para fazer este código funcionar, mesmo quando o cliente está a ligar-se atrás do proxy?

Obrigado antecipadamente!

actualização: eu forneceria uma imagem com o websocketstest naquele computador:enter image description here

No meu computador parece que da mesma forma, excepto uma coisa.: 'Proxy' de HTTP: não.

Author: Luxor, 0000-00-00

1 answers

Por Mais que os comentários ao questions digam, parece que o Proxy não suporta Websockets adequadamente.

Este é um problema comum (algumas empresas de telefones celulares têm proxies que perturbam as conexões websocket) e a solução é usar conexões TLS/SSL.

A questão surge principalmente porque alguns proxies "corretos" (leia: corruptos) os Websocket requisitam cabeçalhos.

No entanto, ao usar o TLS / SSL, os proxies não conseguem ler os dados do cabeçalho( que está encriptado), causando data "pass-through" na maioria dos proxies.

Isto significa que os cabeçalhos chegarão em segurança à outra extremidade e o 'proxy' irá (principalmente) ignorar a ligação... isso ainda pode causar um problema no que diz respeito aos tempos de conexão, mas geralmente resolve o problema.

EDITAR

Repare que os navegadores irão proteger o cliente de misturar conteúdo não encriptado com conteúdo encriptado. Certifique-se que o programa inicia as ligações ws usando a variante wss quando São utilizadas ligações TLS / SSL.

 14
Author: Myst, 2016-08-16 13:52:12