WebSocket не будет подключаться ни к чему, кроме 127.0.0.1 / localhost

Question

У меня есть testapp, состоящий из клиента HTML5 / WebSocket и сервера HTTP / WS.Оба сервера находятся в C #;HTTP-сервер - это моя собственная простая вещь, а WS-сервер также является доморощенным на основе концепций http://nugget.codeplex.com/. HTTP-сервер прослушивает 0.0.0.0:5959 и WS-сервер 0.0.0.0:5960 (принимайте соединения от любого клиента, но на разных портах).

Мой index.html включает в себя некоторый JavaScript, который открывает WebSocket на 'ws://'+document.location.hostname+':5960/' (то есть на тот же IP-адрес, с которого пришла веб-страница, но на порту 5960).Сервер WS отправляет данные образца каждые 100 мс.В общем, это довольно простая демонстрация.Я использую Chrome 12.0 в Windows 7.

Я обнаружил, что HTTP-сервер работает с любого клиента, либо браузер на моем компьютере указывал на 127.0.0.1:5959, либо localhost: 5959, И он работает, когдалюбая машина (моя или удаленная машина ... "удаленная", являющаяся другим ПК на моем столе :) попадает на рабочий 10-сетевой адрес моей серверной машины 10.122.0.159:5959.В HTTP land все работает как положено.

Однако WebSocket работает только на 127.0.0.1 и localhost;удаленные машины могут успешно извлечь HTML из 10.122.0.159:5959, но WebSocket НЕ подключится к 10.122.0.159:5960.Фактически, когда я указываю своему локальному браузеру на его собственный адрес в 10 сетей (10.122.0.159:5959), я получаю тот же результат - HTML загружается, но WebSocket не подключается.

Любые идеи о том, почему это можетпроисходит?Требует ли CORS, чтобы WS использовал тот же порт, с которого исходил HTTP-запрос?Если да, то существует ли специальное исключение из правила для 127.0.0.1?

Большое спасибо,-Dave

Обновление Кажется, это вызвано тем, что прокси-сервер блокирует запросы ws: //.Наша компания использует прокси-сервер для фильтрации контента и всего прочего, и наши браузеры настроены на его использование.Chrome использует настройки прокси-сервера IE, а настройки IE по умолчанию для localhost: , а не для прокси-сервера.Когда я устанавливаю флажок, чтобы локальные соединения также использовали прокси-сервер, мои ws: // запросы к localhost блокируются.И наоборот, когда я снимаю флажок «использовать прокси-сервер», мой сервер выполняет rx запрос WS.Аналогично с удаленным компьютером, если я отключаю прокси на удаленном компьютере, мой сервер выполняет rx запрос ws: //.Так что это прокси, а не CORS или сокет, и теперь я собираюсь изучить настройки прокси с нашими ИТ-специалистами.

Answer 1

Нет ограничений WebSocket для кросс-источника, кроме того, что регулируется защитой CORS при рукопожатии.

Похоже, что-то не так с вашим сервером WebSocket, и он только прослушивает соединения на локальном хосте. Я бы добавил некоторые отладочные данные в подпрограмму OnClientConnect в Nugget (WebSocketServer.cs), чтобы вы могли видеть, когда происходят соединения с сокетами. Если вы действительно думаете, что это не проблема с сервером, я бы предложил использовать wireshark и сравнить подключение localhost с удаленным подключением.

Кроме того, если вы используете прототип SilverLight WebSocket ( README ) в IE 9, то вы ограничены портами 4502-4534 для соединений WebSocket. Возможно, для localhost это ограничение будет снято.

Answer 2

Это действительно было прокси.Вместо того, чтобы просить наших ИТ-специалистов внести изменения (удачи в этом, а?), Я просто отключил прокси для 10.122.0.159 ([Howto for IE / Chrome] [1]).Я кратко экспериментировал с отключением его для протокола ws: //, но не смог заставить его работать, так что пока просто открываем тот один IP-адрес.