2012-07-20 11 views
38

Stiamo provando a far funzionare Socket.io flashsockets in Internet Explorer 9 su HTTPS/WSS. I flashs funzionano su HTTP, ma HTTPS ci sta dando problemi. Stiamo usando la versione 0.8.7 di socket.io e la versione 0.9.1-1 di socket.io-client.Errore HTTPS "lunghezza dati troppo lunga" in s3_pkt.c da Socket.io

Stiamo eseguendo il nostro server WebSocket via SSL sulla porta 443. Abbiamo specificato la posizione del nostro file WebsocketMainInsecure.swf (si tratta di richieste ws interdominio) nella posizione corretta e stiamo caricando il file nello swfobject incorporato su HTTPS.

Abbiamo aperto la porta 843 nel nostro gruppo di sicurezza per la nostra istanza EC2 e il file di criteri di origine incrociata viene reso correttamente tramite HTTP. Non sembra eseguire il rendering su HTTPS (Chrome genera un errore di connessione SSL).

Abbiamo provato due versioni del file WebsocketMainInsecure.swf. Il primo è il file fornito da Socket.io, che è costruito al largo di WebsocketMainInsecure.as che non include la linea

Security.allowInsecureDomain("*"); 

Questo genera l'errore SCRIPT16389: Unspecified error. alla linea WebSocket.__flash.setCallerUrl(location.href).

abbiamo capito che era perché il file SWF non è stato permettendo richieste HTTPS, quindi abbiamo sostituito il file WebSocketMainInsecure.swf con quella che si trova in questa repo: https://github.com/gimite/web-socket-js perché include la linea

Security.allowInsecureDomain("*"); 

in ActionScript codice. Quando abbiamo usato questo, abbiamo visto che la connessione flash-socket continuava a disconnettersi e ricollegarsi in un ciclo infinito. Abbiamo rintracciato l'errore nel file transport.js nella libreria socket.io nella funzione onSocketError del prototipo Transport. Esso genera l'errore:

[Error: 139662382290912:error:1408F092:SSL routines:SSL3_GET_RECORD:data length too long:s3_pkt.c:503:] 

Abbiamo anche provato l'aggiornamento sia socket.io e socket.io-client alla versione 0.9.6 e abbiamo ancora ricevuto l'errore Access is denied.

Questo errore è stato molto difficile eseguire il debug, e ora non sappiamo come far funzionare i flashsocket. Ci chiediamo se potrebbe avere a che fare con l'utilizzo di una versione precedente di socket.io, o forse che il nostro file server dei criteri non accetta richieste HTTPS, o forse persino il modo in cui il file WebSocketMainInsecure.swf dal web- socket-js github repo è stato costruito relativamente a ciò che si aspetta socket.io-client.

+1

Questo potrebbe essere meglio chiesto in un forum diverso. . . ServerFault potrebbe essere una buona scommessa. Ecco [una domanda da lì su un errore simile] (http://serverfault.com/questions/402152/error-in-openssl-s-client-data-length-is-too-long), che potrebbe dare qualche indizio – iND

+1

@iND Ho visto questa domanda ma non sono sicuro se mi aiuta, cosa ne pensi? – user730569

+1

Ho una conoscenza molto limitata del debugging dell'interazione con il server, e questo potrebbe non essere il forum con il maggior numero di esperti in quell'area. È possibile ottenere risposte migliori nei forum più mirati. Tuttavia, ciò implica che questo potrebbe non essere un problema Flash. Il messaggio di errore è lo stesso, e il numero di riga è solo uno lontano dalla tua riga di errore, quindi penserei che le soluzioni - se ignori le informazioni relative a LDAP - potrebbero avere qualche rilevanza qui. – iND

risposta

1

Il tempo non è sicuro funziona. Ma ecco la mia idea/suggerimento:

  1. Idea: Suppongo che voi (forse) è tentato di accedere a un URL che è troppo lungo. Questo accade se i dati vengono spesso trasmessi tramite GET-Parameters. Il limite ufficiale per un URL è inferiore a 512 byte.

Dettagli: Le specifiche HTTP indicano che una linea di protocollo può essere al massimo di 512 byte. Se più a lungo il server può rifiutare la richiesta o potrebbe non essere in grado di gestire la richiesta. La prima riga in HTTP con un GET-requet è come "GET/percorso/a? Param1 = data1 & param2 = data2 & ... HTTP/1.1" che dovrebbe essere inserita in 512 byte. Per le richieste POST non esiste tale limitazione ..

Tuttavia il tuo errore sembra provenire da qualche implementazione SSL (openSSL?): Riferimento a s3_pkt.c alla riga 503 (ho trovato un file come questo qui: http://www.opensource.apple.com/source/OpenSSL/OpenSSL-7.1/openssl/ssl/s3_pkt.c) ma sembra essere diverso; Non conosco i dettagli e sto solo speculando: potrei pensare che l'implementazione openSSL abbia un supporto limitato per lunghe richieste GET (dato che non sono conformi a HTTP) e le rifiuta semplicemente in questo modo ...

Vedo ora queste possibilità: 1. Soluzione: utilizzare POST anziché GET-Requests per trasmettere set di dati più lunghi. Verifica se questo funziona ... 2. Prova a sostituire openssl-installation o libopenssl sul server utilizzato; è forse rotto o obsoleto? 3. una richiesta di aiuto da parte degli sviluppatori di OpenSSL ...

Speranza che aiuta ...

1

edificio Prova OpenSSL con SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER (credito per Steven Henson e Jaaron Anderson dalla mailing list OpenSSL).

+0

grazie! ho bisogno di creare OpenSSL con questa opzione, o posso semplicemente specificare l'opzione '-bugs' quando eseguo' s_client' per impostare l'opzione? – user730569

+0

E se lo ricostruisco, come posso specificare questa opzione? – user730569

Problemi correlati