Поиск неисправностей веб-сайта путем изучения HTTP-трафика

Active Server Pages (ASP) компании Microsoft является предшественником ASP.NET. ASP был простым скриптовым движком, в котором не хватало инструментария, столь используемого разработчиками ASP.NET сегодня, и в большей степени это отладчик. Отладка скрипта ASP обычно заключалась в заполнении кода выражениями Response.Write, чтобы вывести значения переменных в различных точках времени жизненного цикла скрипта. Отладка страницы ASP.NET намного проще благодаря отладчику Visual Studio, который позволяет вам установить точки остановки, прошагать по выполняемому коду, использовать окна Watch - окно для просмотра значений переменных, в то время как они изменяются, а также окно Intermediate для вычисления выражений во время отладки.

Хотя отладчик Visual Studio значительно улучшил процесс отладки, существуют случаи, когда отладчик серверной стороны не приносит много пользы. В определенных случаях проблема заключается не в серверном коде, а в том, что посылается от клиента на сервер (или наоборот). Такие случаи  нередко  встречаются  при создании веб-приложений, основанных на AJAX, так как данные, которыми обмениваются клиент и сервер во время частичного страничного постбэка, влияют на код, выполеннный на серверной стороне, а также на способ обновления страницы в ответ. Данная техника также очень пригодна при отладке страниц, которые выполняют различные команды Response.Redirect , основываясь на различных параметрах, либо при попытке определения почему изображения, видео или внешнее содержимое не загружается корректно на веб-странице.

В отличие от отладчика серверного кода, изучение HTTP-трафика, посланного между клиентом и сервером, обычно выполняется на клиентской стороне - а именно, от обозревателя, а не из Visual Studio. Fiddler - это бесплатный и отличный инструмент для отладки HTTP-трафика. Данная статья предоставляет обзор Fiddler и демонстрирует способ его использования в помощь к отладке. Читайте далее, чтобы узнать больше об этом!

Зачем нужно просматривать HTTP-трафик

Каждый раз, когда обозреватель осуществляет запрос на веб-сервер - будь это для веб-страницы, изображения в пределах веб-страницы, CSS-файл, внешний JavaScript-файл, вызов веб-сервиса или все что угодно - это выполняется в виде HTTP-запроса от обозревателя на веб-сервер. В HTTP-запросе обозреватель посылает на сервер название ресурса, который ему необходим (к примеру, Default.aspx), и также другую опциональную информацию. К примеру, при отсылке формы обозреватель также высылает названия и значения полей данной формы. При получении данного сообщения веб-сервер ищет данный ресурс и возвращает его содержимое. Эти данные могут быть двоичной информацией (для изображения, MP3, ZIP файла и т.д.), статической текстовой информацией в текстовом файле или HTML-странице, или динамически-сгенерированным текстовым содержимым, как в случае с веб-страницей ASP.NET или веб-сервисом. Обозреватель затем отображает возвращенные данные, основываясь на их типе.

Информация нижнего уровня, которая перемещается между клиентом и сервером, обычно "верна" и работает, как положено. Обычно когда существует проблема в странице ASP.NET , она заключается в коде фонового класса данной страницы. В таких случаях отладчик Visual Studio является лучшим инструментом по нахождению и исправлению проблемы. Но в других случаях проблема или ее объяснение не содержатся в коде серверной части, а находятся в информации, обмениваемой между клиентом и сервером. Для таких случаев исследование трафика, перемещаемого между клиентом и сервером, является хорошим инструментом обнаружения источников проблемы.

Представьте себе следующую проблему: у вас есть страница ASP.NET с формой, которая содержит элементы управления TextBox, Button и Label. Идея заключается в том, что пользователь вводит какое-то значение в TextBox и посылает форму, после чего на экране отображается некоторая информация в элементе Label. Такую функциональность можно реализовать путем создания обработчика для события Click элемента Button и написания некоторого кода для отображения соответствующей информации в элементе Label , основываясь на пользовательском вводе в TextBox. После того, как вы напишете данный код, вы решите его протестировать, и если вы введете текст в TextBox и затем нажмете на кнопку, страница  выполнит постбэк, и желаемые данные будут отображены  на странице. Еще немного протестировав у вас что-то может пойти не так - все вроде работает, как должно, если пользователь посылает заполненную форму, нажав кнопку (Button), но если вы нажмете клавишу Enter в то время как фокус будет на TextBox , то страница выполнит постбэк, но элемент Label ничего не отобразит. Ещё более странным является то, что это все происходит при тестировании с Internet Explorer. Интересно, почему?

Вашим первым шагом на пути к решению данной проблемы может быть использование отладчика Visual Studio. Вы установите точку остановки в обработчиках события Page_Load и Click. Это докажет вам, что страница была отослана обратно при нажатии на кнопку Button или в момент, когда пользователь нажмет клавишу Enter , имея фокусировку на элементе TextBox, и раскроет вам факт, что обработчик события Click элемента Button выполняется тогда, когда кнопка явно нажата (а не в случае нажатия клавиши Enter). Но такой тип отладки предоставляет нам ответа на вопрос, почему мы имеем такую разницу в поведении.

Это такой тип проблемы, где анализ HTTP-трафика, посланного между клиентом и сервером, как раз является решением. Если вы сравните HTTP-трафик, посланный при нажатии кнопки на форме, и тот, что был послан при нажатии клавиши Enter, то вы заметите, что обозреватель не отсылает название и значение кнопки во втором случае, но отсылает эту пару значений в случае с кнопкой на форме. Для того, чтобы ASP.NET знал о том, что была нажата кнопка на форме, и следовательно вызвал событие Click , от обозревателя должны быть отосланы название и значение кнопки. Данная разница объясняет наблюдаемое поведение.

Указанный выше пример является редким и конкретным случаем, когда исследование HTTP-трафика является первостепенным решением удачной отладки проблемы. Тем не менее, такой тип анализа очень  пригоден во многих сценариях. Исследование HTTP-трафика обычно является самой первой вещью, которую нужно сделать при отладке веб-приложения, поддерживающего AJAX. Анализ HTTP-трафика полезен в случаях, когда наблюдается наличие немногих перенаправлений с одной страницы на другую, для того чтобы установить, какие страницы были посещены и какая информация была послана каждой из них. Аналогично, анализ HTTP-трафика пригоден в определении причин неисправности изображений или отсутствия внешнего содержимого. К примеру, если файл изображения или CSS-файл находятся в каталоге, который недоступен по причине разрешений или правил авторизации (URL authorization rules), то обозреватель отобразит иконку неисправного изображения, либо же не применит правила CSS-файла. Чтобы определить причину этого, вы можете исследовать HTTP-ответ, возвращенный от данных внешних файлов при запросе обозревателя, где вы явно увидите то, что данные не могли быть получены из-за проблем с правами (либо по любой другой причине).