Может ли поставщик услуг Интернета выборочно блокировать.png, .jpg, .js, .css и другие с внутреннего HTTP-сервера?

Это вопрос специалиста, так как он касается очень маленького встроенного веб-сервера в отличие от обычного веб-сервера (например, Apache, IIS) и больше связан с маршрутизацией через ISP.

Я программист, отвечающий за реализацию встроенного веб-сервера внутри аппаратного продукта. Это в основном потребительское устройство, которое находится в помещении клиента. Заказчик может дополнительно использовать внутренний веб-сервер для выполнения настройки, и, очевидно, он может перенести порт через свой маршрутизатор, если он хочет, чтобы он мог получить к нему доступ через Интернет.

Я пытаюсь исследовать странную ситуацию, когда устройство, установленное в определенном помещении, отвечает на запросы .htm а также .cgi файлы абсолютно нормально, и он также ответит 404 как это должно быть при запросе несуществующего файла. Тем не менее, если .png, .jpg, .css, или же .js (и, без сомнения, многие другие) запрашивается, то что происходит, HTTP-запрос зависает на неопределенное время и в конечном итоге истекает. На этом этапе браузер просто отображает то, что он смог загрузить после этого времени, что обычно представляет собой просто необработанный HTML без каких-либо ресурсов изображений, стилей или скриптов. (Я вижу все это, используя вкладку "net" в 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 ответ может быть настолько большим, насколько ему нравится, и он работает.