РЕДАКТИРОВАТЬ 2: Согласно комментарию, обновленный вопрос от фрагментации до сегментации.
РЕДАКТИРОВАТЬ: Я сузил эту проблему только до Windows 10 - похоже, что проблема с усилением IE была проблемой в 2012 R2, что наводит меня на мысль, что 8.1 тоже затронута. Исходное содержание вопроса следующее:
Я получаю сегментированный HTTP-ответ с веб-сервера.
Первый пакет (709 на первом изображении) выглядит так: 2 - как видите, он содержит заголовки, а затем содержимое. Второй пакет (710 на первом изображении) выглядит так: 3. Остальные пакеты не имеют отношения к этому вопросу, но они содержат остальной HTML-контент.
Проверка повторно собранных данных в Wireshark показывает правильный ответ HTTP: 4, однако ЛЮБОЕ пользовательское приложение (браузер или не браузер) получит это: 5. Как видите, похоже, что содержимое HTML, которое ПОСЛЕ заголовков в первом пакете отсутствует, вместо этого данные следуют от второго до последнего пакета. Чтобы все было еще смешнее, это происходит только в том случае, если приложение отправляет запрос HTTP / 1.1 или HTTP / 1.0 - отправка HTTP / 1.2, HTTP / 0.9, HTTP / 2.0 или даже любых произвольных данных, таких как «GET / AAA», приведет к веб-серверу. отвечает HTTP / 1.1 и приложение получает правильные данные: 6. Как бы то ни было, похоже, что что-то в сетевом стеке пытается оптимизировать HTTP-запросы, но мне не удалось найти никакой информации об этом. Проблема проявляется только в Windows 8+ (или 8.1+, нет машины 8 для тестирования), включая серверные версии. Нет проблем с Windows 7 и старше или любой другой системой на базе * nix. Это та же проблема, которую можно увидеть на форумах TP-Link (http://forum.tp-link.com/showthread.php?93626-TL-SG105E-v2-Web-interface-unresponsive-Config-utility-works) однако я почти уверен, что это проблема с реализацией Windows, которая не работает в этом конкретном случае (даже если веб-сервер делает что-то неправильно, это работает в старых системах Windows и * nix).
Я открыт для любых предложений, так как, откровенно говоря, сейчас я схожу с ума.
Итак, для всех, кто ищет ответ - оказывается, Дэвид Шварц был прав, проблема была в программном обеспечении безопасности, однако кажется, что это можно классифицировать как ошибку Bitdefender - даже после полного отключения не было никаких изменений - только его удаление дали достойный результат. Кажется, его драйвер WFP брандмауэра (bdfwfpf.sys) всегда работает независимо от настроек и пакета, который вы установили (тот, который у меня есть, не поддерживает функции брандмауэра). Мне это кажется очень агрессивным, поэтому мое решение было столь же агрессивным - удалить файл драйвера брандмауэра WFP и заблокировать разрешения для соответствующих разделов реестра.
Вероятно, это комбинация двух ошибок: сервер отправляет неверный ответ и AV обрабатывает этот неправильный ответ, искажая его. Сервер отправляет ответ с кодом 401, но нет WWW-Authenticate заголовок. Это недействительно согласно стандарт HTTP:
Ответ ДОЛЖЕН включать поле заголовка WWW-Authenticate (раздел 14.47), содержащее запрос, применимый к запрошенному ресурсу.
это WWW-Authenticate заголовок, содержащий область, необходим, чтобы браузер мог либо предложить пользователю предоставить учетные данные для этой области, либо использовать кэшированные учетные данные. Отправка нет WWW-Authenticate но вместо этого отправка HTML-страницы, которая даже содержит сценарий, определенно является неправильным поведением сервера.
Обратите внимание, что код ответа 401 должен использоваться только в том случае, если необходимо использовать диалоговое окно проверки подлинности, встроенное в браузеры, а затем необходимо указать область. Если кто-то строит свою собственную систему аутентификации вне HTTP (то есть типичные логины внутри HTML, как в данном случае), то необходимо использовать код ответа 200.
