Ошибка HTTPS "длина данных слишком длинная" в s3_pkt.c из Socket.io

Были попытки получить flash файлы Socket.io для работы в Internet Explorer 9 по протоколу HTTPS/WSS. Флэш-память работает через HTTP, но HTTPS дает нам проблемы. Использовали версию socket.io 0.8.7 и версию socket.io-client 0.9.1-1.

Запустили наш сервер websocket через SSL на порту 443. Weve указал местоположение нашего файла WebsocketMainInsecure.swf(это междоменные запросы ws) в правильном месте и загружал файл в swfobject, встроенный через HTTPS.

Мы открыли порт 843 в нашей группе безопасности для нашего экземпляра EC2, и файл политики перекрестного происхождения успешно обрабатывается через HTTP. Кажется, что он не обрабатывает HTTPS (Chrome выдает ошибку SSL-соединения).

Weve попробовал две версии файла WebsocketMainInsecure.swf. Первый - это файл, предоставленный Socket.io, который построен на основе WebsocketMainInsecure.as, который не включает строку

Это вызывает ошибку SCRIPT16389: Unspecified error. в строке WebSocket.__flash.setCallerUrl(location.href).

Мы полагали, что это связано с тем, что SWF файл не разрешал HTTPS-запросы, поэтому мы заменили файл WebSocketMainInsecure.swf на тот, который был найден на этом репо: https://github.com/gimite/web-socket-js, поскольку он включает

в коде ActionScript. Когда мы это использовали, мы увидели, что соединение flashsocket продолжало отсоединяться и снова соединяться в бесконечном цикле. Мы отслеживали ошибку до файла transport.js в библиотеке socket.io в функции onSocketError прототипа Transport. Он выдает ошибку:

Мы даже попробовали обновить как socket.io, так и socket.io-client до версии 0.9.6, и мы по-прежнему получили ошибку Access is denied.

Эта ошибка была очень сложной для отладки, и теперь она не понимала, как заставить flashsockets работать. Интересно, может ли это иметь отношение к использованию более старой версии socket.io или, возможно, что наш файловый сервер политики не принимает HTTPS-запросы или, может быть, даже тот способ, с помощью которого файл WebSocketMainInsecure.swf из веб-сокета-js github репо было построено относительно того, что ожидает сокет .io-client.

Ответы

Ответ 1

Я не уверен, что он работает. Но вот моя идея/предложение:

Идея: Я предполагаю, что вы (возможно) попытались получить доступ к URL-адресу, который слишком длинный. Это происходит, если данные часто передаются через GET-параметры. Официальный лимит для URL-адреса составляет менее 512 байт.

Подробности. В спецификации HTTP указано, что строка протокола может быть не более 512 байт. Если дольше сервер может отклонить запрос или не сможет обработать запрос. Первая строка в HTTP с GET-реквизитом подобна "GET/path/to? Param1 = data1 & param2 = data2 &... HTTP/1.1", которая должна соответствовать 512 байтам. Для запросов POST нет такого ограничения..

Однако ваша ошибка возникает из некоторой реализации SSL (openSSL?): ссылаясь на s3_pkt.c в строке 503 (я нашел такой файл здесь: http://www.opensource.apple.com/source/OpenSSL/OpenSSL-7.1/openssl/ssl/s3_pkt.c), но, похоже, отличается; Я не знаю деталей, и я просто размышляю: я мог подумать, что реализация openSSL имеет ограниченную поддержку длинных запросов GET (поскольку они не соответствуют HTTP) и просто отвергает их таким образом...

Я вижу эти возможности сейчас: 1. Решение. Используйте POST вместо GET-Requests для передачи более длинных наборов данных. Посмотрите, работает ли это... 2. Попробуйте заменить вас openssl-install или libopenssl на используемом сервере; возможно, он сломан или устарел? 3. Попробуйте запросить помощь у разработчиков openssl...

Надеюсь, что это поможет...

Ответ 2

Попробуйте создать OpenSSL с SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER (кредит Стивен Хенсон и Яарон Андерсон из списка рассылки OpenSSL).