ASP.NET приложение демонстрирует странное поведение через брандмауэр

Question

Эта проблема была решена благодаря вашим предложениям. Подробности смотрите внизу. Большое спасибо за вашу помощь!

Наш веб-сайт ASP.NET доступен из нескольких специальных и высоконадежных международных отделений. Он работал нормально, но мы добавили еще одно местоположение клиента, которое демонстрирует очень странное поведение.

В частности, когда пользователь вводит критерии поиска и нажимает кнопку поиска, список результатов возвращается пустым. Он даже не отображает текст «0 результатов возвращен», так что элемент управления Repeater вообще не связывается. Подобное поведение проявляется в некоторых, но не во всех других частях сайта. Пользователь может нормально зайти на сайт и отобразится информация о его профиле.

Я вошел на сайт локально, используя те же учетные данные, что и они, и сайт работает хорошо. Мы тщательно прошли все этапы, поэтому я уверен, что это не проблема пользователя.

Я связываю результаты поиска в Page_Load страницы результатов поиска при первой загрузке (критерии указаны в строке запроса). т.е.

if (!IsPostBack) {
  BindResults();
}

Я могу повторить то же самое поведение локально, закомментировав вызов метода BindResults ().

Кто-нибудь знает, как рассчитывается значение IsPostBack? Возможно ли, что их высокобезопасная настройка брандмауэра заставит IsPostBack всегда возвращать true, даже если это перенаправление с другой страницы? Это может быть красная сельдь, так как проблема может быть в другом месте. Хотя он точно повторяет результат.

У меня нет доступа к сайту, поэтому устранение неполадок ограничивается предоставлением им инструкций и просьбой сообщить мне результат.

Спасибо за ваше время!

Информация о дополнении: Клиент находится за брандмауэром Microsoft ISA 2006, на котором выполняются правила по умолчанию. Сайт был добавлен в список доверенных сайтов Internet Explorer и опробован в FireFox и Google Chrome, все с одинаковым результатом.

РЕШЕНИЕ : Победителем для меня стало предложение использовать Fiddler. Какой отличный инструмент, без которого не должен обходиться ни один веб-разработчик. Используя это, я смог удалить различные заголовки из запроса, пока не воспроизвел проблему. На самом деле, причиной этой ошибки было два фактора, как это часто бывает с такими запутанными проблемами.

Фактор первый - где это возможно, веб-приложение использует сжатие GZIP, поддерживаемое всеми основными браузерами. Брандмауэр удалил заголовок, который указывает поддержку распаковки GZIP (Accept-Encoding: gzip, deflate).

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

Answer 1

Если они вообще разбираются в технологиях, я бы попросил их загрузить Fiddler или что-то подобное, захватить весь HTTP-сеанс, а затем отправить вам сохраненный сеанс. Может быть, что-то там будет торчать.

Тем временем, посмотрите, сможете ли вы получить установку ISA Server (пробную установку, если нужно) или одну из MSDN, если у вас есть или знаете кого-либо с подпрограммой), и посмотрите, сможете ли вы реплицировать его локально.

Answer 2

Проверьте журналы IIS, чтобы узнать, поступает ли запрос на ваш сервер. Настройка ISA может кэшировать первоначальный запрос и обрабатывать его в последующих запросах.

Answer 3

Местоположение, местоположение, местоположение. Проверьте культуру пользователя. Обычно это вызывает проблемы.

Answer 4

Не могли бы вы создать тестовую страницу поста, которая передает те же действия, что и ваша страница поиска, и в Page_Load записать обратно все посты, чтобы убедиться, что они проходят, особенно __VIEWSTATE.

foreach (string key in Request.Form)
{
    Response.Write("<br>" + key + "=" + Request.Form[key]);
}

Затем попросите одного из пользователей переслать назад то, что они увидят на этой тестовой странице.

РЕДАКТИРОВАТЬ: Есть документация, что некоторые брандмауэры могут повредить VIEWSTATE и некоторые методы, чтобы обойти его: Просмотр состояния обзора

Answer 5

О, да. Это точно не "_EVENTTARGET" Кстати ...

Я знаю это, поскольку Ra-Ajax НЕ передает ни один из этих параметров на сервер, и они (запросы Ra-ajax) обрабатываются как запросы IsPostBack ...

Answer 6

Это может быть какой-то прокси, который создает запрос GET из данного запроса POST ...

Я не уверен, как рассчитывается IsPostBack, но я предполагаю, что он проверяет HTTP-запрос, чтобы определить, является ли он POST или GET ...

Answer 7

Возможно ли, что клиент отключил Javascript и не получает значение формы _EVENTTARGET?