0

My web app runs under Tomcat, it uses AJAX requests very intensively, and during the development process I have to redeploy the web app intensively too. After the redeployment I usually simply refresh the page knowing that the user session is dropped, but I always get to the scenario described below:

  1. Go to some page, a really big page with many JS-scripts included, that actually makes those intensive AJAX requests.
  2. Stop Tomcat or redeploy the web app.
  3. Refresh the page.
  4. Enter the credentials in the sign-in form to authenticate.
  5. Suddenly get the last AJAX request response in the browser window and the AJAX request URL in the URL bar.

Wow... It looks strange for me that AJAX request URLs appear in the URL bar along with their response in the web page display area. This actually happens to Firefox and Chrome (haven't tested it in other browsers). Unfortunately, I cannot reproduce the same behavior in a simple page written from scratch. Frankly speaking, I don't really understand what happens to such requests and why do browsers "think" if AJAX requests/responses are entered in URL bar by user...

Your possible explanations or hints for such a strange behavior are very and very appreciated. Thanks!

(Perhaps it can help: All AJAX requests are performed with jQuery 1.4.2)

Lyubomyr Shaydariv
  • 20,327
  • 12
  • 64
  • 105
  • @ChristopherSchultz, it happened for all versions of Tomcat 6.0.x, and it's probably reproducible on Tomcat 7. Now I'm on 6.0.32. – Lyubomyr Shaydariv Jul 31 '12 at 15:06
  • It's possible that this is just spec-compliant behavior for FORM-based authentication, though I would have expected the **first** AJAX response to show up in your browser and not the last one. – Christopher Schultz Jul 31 '12 at 15:10
  • @ChristopherSchultz as I understood later, the FORM-based authenticator returned a redirection. Please see my answer below, and thank you for the hint to look into the authentication module response - that actually solved the problem! – Lyubomyr Shaydariv Jul 31 '12 at 19:11

1 Answers1

0

I'm very sorry, as I understood later, the question is not complete, because there was another pitfall I didn't mention, so no one couldn't answer the question in principle. The reason of the bug was hiding in the... <body onunload="..."> tag definition. That was quite unexpected, but that code contained some AJAX request that must be invoked when a user leaves the page. I only realized that the authenicating module (FORM, j_security_check) returned a response (HTTP 302) containing the Location header - so that was the reason why browsers did redirects.

The exact scenario was like that:

  • Open the page containing <body onunload="some_ajax_here">.
  • Log out the app using another tab so you could stay at the same page.
  • Refresh the page so some ajax could be invoked - this AJAX request is not now allowed because it's a secured part of the application (you get the forwarded content of the login page).
  • Enter the credentials and now oops you get to the result of some ajax directly in the browser window.

As the quick fix, and I hope the final one, I added another request following that AJAX request:

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

So the HTML page script simply makes self-page request the last one - j_security_check returns the Location referring the last used HTML page, and the redirect works fine. Perhaps my explanation is not clear and may be not complete or even full of mistakes, but it looks like that in general. I'm very sorry once again, and thank you @ChristopherSchultz!

Lyubomyr Shaydariv
  • 20,327
  • 12
  • 64
  • 105