Ответ 1
Выяснил это. Оказывается, Chrome только что включил компрессию по веб-сайтам по умолчанию. Мне просто нужно было изменить сервер websocket на моем конце, чтобы отказаться от этого расширения, и Chrome вернется к простому тексту.
Я использую websockets без проблем в течение нескольких месяцев для связи между Chrome и моим приложением localhost. Внезапно, с последней версией Chrome, данные не проходят чисто.
В расширении javascript Chrome соответствующая часть кода:
window.ws = new WebSocket("ws://localhost:13000/");
window.ws.onopen = function () {
window.ws.send('GO');
В моем приложении С#:
string msg = ASCIIEncoding.UTF8.GetString(buffer);
Debug.WriteLine(msg);
В течение нескольких месяцев это работало нормально, и я получал "GO" обратно день за днем. Теперь я получаю в буфере приема 4 байта {114,247,7,0)
, который не переводит на "GO" в любой кодировке, которую я могу найти. Кто-нибудь знает, что может произойти? Я смущен, поскольку я не коснулся конца кода (хром или слушатель).
Ура!
PS: полная версия бета-версии Chrome версии 19.0.1084.15
Выяснил это. Оказывается, Chrome только что включил компрессию по веб-сайтам по умолчанию. Мне просто нужно было изменить сервер websocket на моем конце, чтобы отказаться от этого расширения, и Chrome вернется к простому тексту.
Прочитайте некоторые данные о Masking. Браузер может отправлять сообщения с включенным Masking, и он добавит дополнительные 4 байта в фрейм, который будет применять маскировку к вашим сообщениям. Браузеры могут включить или отключить его, поэтому на стороне сервера вы должны поддерживать оба варианта и использовать маскирование, если фрейм содержит бит с включенным маскированием.
Посмотрите, как применяется маскировка на основе RFC 6455