Это вопрос специалиста, поскольку он касается очень небольшого встроенного веб-сервера, в отличие от обычного веб-сервера (например, Apache, IIS), и больше связан с маршрутизацией через ISP.
Я программист, отвечающий за внедрение встроенного веб-сервера в аппаратное обеспечение. По сути, это потребительское устройство, которое находится в помещении клиента. При желании заказчик может использовать внутренний веб-сервер для настройки, и, очевидно, он может переадресовать его через свой маршрутизатор, если захочет, чтобы получить к нему доступ извне через Интернет.
Я пытаюсь расследовать странную ситуацию, когда устройство, установленное в определенном помещении, отвечает на запросы .htm и .cgi файлов абсолютно нормально, и он также ответит 404 как он должен поступать, когда запрашивается несуществующий файл. Однако если .png, .jpg, .css, или .js (и, без сомнения, многие другие) запрашивается, тогда происходит то, что HTTP-запрос зависает на неопределенное время и в конечном итоге истекает время ожидания. На этом этапе браузер просто отображает то, что он смог загрузить после этого времени, обычно это необработанный HTML-код без каких-либо ресурсов изображения, стиля или сценария. (Я все это вижу, используя вкладку «Сеть» в Firebug.)
Все, что я знаю об устройстве в помещении, - это то, что оно находится в доме, который, по-видимому, использует интернет-провайдер Virgin Media, за довольно стандартным домашним модемом / маршрутизатором. К сожалению, на данный момент я не могу узнать больше, да и сам физически не могу до этого добраться.
HTTP-сервер в настоящее время настроен для порта 80.
Установщик сообщает мне, что доступ к HTTP-серверу абсолютно нормальный при доступе в помещении локально; то есть все изображения и т. д. загружаются без проблем. Более того, я никогда раньше не сталкивался с подобной проблемой с продуктом. Еще более странным является тот факт, что в предыдущем нашем продукте, установленном там, был почти такой же веб-сервер внутри - и вообще не было этой проблемы. Поэтому я понятия не имею, могло это быть совпадением или нет.
Есть ли вообще возможность того, что интернет-провайдер может применять фильтрацию или иным образом возиться с входящими HTTP-запросами? На данный момент это единственная соломинка, за которую я должен ухватиться.
Используемый веб-сервер - это HTTP-сервер, который входит в состав библиотеки Keil MDK-ARM. По сути, продукт представляет собой небольшую часть специального оборудования с процессором ARM, на котором работает облегченная ОСРВ Keil, которая также является частью MDK-ARM. Я не верю, что могу сказать что-то значимое о фактическом функционировании коробки.
РЕДАКТИРОВАТЬ: Дополнительная подсказка Wireshark
Я делал журналы Wireshark, когда пытался напрямую запросить тип файла «проблема», например один из .css или .js файлы. Я обнаружил следующее:
Вместо того, чтобы видеть поток из одного или нескольких TCP-пакетов, которые вместе образуют действительный HTTP-ответ, помимо обычных пакетов ACK я вместо этого вижу только один TCP-пакет, содержащий то, что предположительно является частью HTTP-ответа. Wireshark помечает этот пакет как «Продолжающийся или не HTTP-трафик [неверный пакет]», потому что из-за отсутствия заголовка HTTP в пакете он не может определить, что это такое.
При дальнейшем осмотре я понимаю, что эти одиночные «искаженные» пакеты, которые я получаю всякий раз, когда я запрашиваю проблемный тип файла, на самом деле содержат полезную нагрузку всего в четыре байта фактически запрошенного HTTP-файла. Например, четырехбайтовая полезная нагрузка пакета может быть ID=b, что соответствует ID=blahblah в начале .js файл, который я запросил. (Я создал этот конкретный пример, но это последовательное поведение, которое я наблюдаю при запросе .css и .js файлы).
Короче говоря, если я хочу вернуть полный HTTP-ответ в одном или нескольких TCP-пакетах и включая HTTP-заголовок, вместо этого я просто возвращаю один пакет с полезной нагрузкой всего в четыре байта, которые, как я знаю, составляют четыре байта от запрашивается исходный файл.
Изменить 2: В дополнение к вышесказанному я понял, что любое изображение, которое очень мало в байтах (скажем, менее 1 КБ), успешно возвращается. Как будто все в порядке, если ответ умещается в один TCP-пакет. Если больше, то возникает странная проблема, описанная выше. Но для .htm или .cgi ответ может быть сколь угодно большим, и это работает.
Да, возможно, но вряд ли они так делают.
(Убедитесь, что больше ничего не запрошено, прежде чем звонить провайдеру. Также может быть неправильный MIME-тип ресурса, который что-то между вашим сервером и клиентом (или даже последним) захлебывается).