AJAX GET-запрос появляется в адресной строке после обновления страницы в Tomcat, которая перезапускается

Мое веб-приложение работает под управлением Tomcat, оно очень интенсивно использует запросы AJAX, и в процессе разработки мне также приходится интенсивно переустанавливать веб-приложение. После повторного развертывания я обычно просто обновляю страницу, зная, что сессия пользователя сброшена, но всегда получаю сценарий, описанный ниже:

  1. Перейдите на какую-нибудь страницу, действительно большую страницу с множеством включенных JS-скриптов, которая на самом деле выполняет эти интенсивные запросы AJAX.
  2. Остановите Tomcat или повторно разверните веб-приложение.
  3. Обновите страницу.
  4. Введите учетные данные в форму входа для аутентификации.
  5. Неожиданно получите последний ответ на запрос AJAX в окне браузера и URL-адрес запроса AJAX в строке URL.

Ничего себе... Мне кажется странным, что URL-адреса запросов AJAX отображаются в строке URL вместе с их ответом в области отображения веб-страницы. Это на самом деле происходит с Firefox и Chrome (не проверял это в других браузерах). К сожалению, я не могу воспроизвести такое же поведение на простой странице, написанной с нуля. Честно говоря, я не очень понимаю, что происходит с такими запросами и почему браузеры «думают», если пользователь вводит AJAX-запросы/ответы в адресную строку...

Ваши возможные объяснения или намеки на такое странное поведение очень и очень ценятся. Спасибо!

(Возможно, это поможет: все запросы AJAX выполняются с помощью jQuery 1.4.2)


http browser get-request ajax tomcat
person Lyubomyr Shaydariv    schedule 31.07.2012    source источник
comment
@ChristopherSchultz, это произошло для всех версий Tomcat 6.0.x и, вероятно, воспроизводимо на Tomcat 7. Сейчас я на 6.0.32.   -  person Lyubomyr Shaydariv    schedule 31.07.2012
comment
Возможно, это просто поведение, соответствующее спецификации для аутентификации на основе FORM, хотя я ожидал, что первый ответ AJAX появится в вашем браузере, а не последний.   -  person Christopher Schultz    schedule 31.07.2012
comment
@ChristopherSchultz, как я понял позже, аутентификатор на основе FORM вернул перенаправление. Пожалуйста, смотрите мой ответ ниже, и спасибо за подсказку, чтобы изучить ответ модуля аутентификации - это фактически решило проблему!   -  person Lyubomyr Shaydariv    schedule 31.07.2012

Ответы (1)


arrow_upward
0
arrow_downward

Очень извиняюсь, как я понял позже, вопрос не полный, потому что был еще один подводный камень, о котором я не упомянул, так что ответить на вопрос в принципе никто не мог. Причина бага скрывалась в... определении тега <body onunload="...">. Это было довольно неожиданно, но этот код содержал некоторый AJAX-запрос, который должен быть вызван, когда пользователь покидает страницу. Я только понял, что модуль аутентификации (FORM, j_security_check) вернул ответ (HTTP 302), содержащий заголовок Location, так что это было причиной, почему браузеры выполняли перенаправления.

Точный сценарий был таким:

  • Откройте страницу, содержащую <body onunload="some_ajax_here">.
  • Выйдите из приложения, используя другую вкладку, чтобы вы могли остаться на той же странице.
  • Обновите страницу, чтобы можно было вызвать некоторый ajax — этот запрос AJAX теперь не разрешен, поскольку он является защищенной частью приложения (вы получаете пересылаемый контент страницы входа) .
  • Введите учетные данные, и теперь вы получаете результат некоторого ajax прямо в окне браузера.

В качестве быстрого исправления, и я надеюсь, что окончательного, я добавил еще один запрос после этого запроса AJAX:

$.ajax({
    async: true,
    method: "GET",
    url: document.location.pathname + document.location.search
});

Таким образом, сценарий HTML-страницы просто делает запрос на собственную страницу последним — j_security_check возвращает Location, ссылающийся на последнюю использованную HTML-страницу, и перенаправление работает нормально. Возможно, мое объяснение неясно и может быть неполным или даже полным ошибок, но в целом выглядит так. Мне еще раз очень жаль, и спасибо @ChristopherSchultz!

person Lyubomyr Shaydariv    schedule 31.07.2012