What I know:
When I make an ajax call to my server, a handler is created, the request is sent, my php script receives the request and processes it and--if I tell it to--sends back a response, which my javascript parses as I require. I also know that php will continue to process the request even if the user closes the browser or changes pages (its all being done on the server side, so why wouldn't it? ^.^).
What I need to know:
Is the ajax handler killed when the user changes pages within my site? For example: The user is on mysite/foo.php. They click a link that sends off an ajax request to my server. The response of that request is to be shown in div#resp on foo.php. They then navigate to mysite/bar.php before the response is received.
If I load the same javascript functions and have the needed div#resp element on bar.php, can the javascript function that called the ajax still receive the response from the server and pass it into the div#resp on bar.php, thus showing the response? Or is the original ajax handle no longer available? And if it is no longer available in standard javascript, is there some implantation in jQuery that will allow me retrieve the response and show it on bar.php?
What I know:
When I make an ajax call to my server, a handler is created, the request is sent, my php script receives the request and processes it and--if I tell it to--sends back a response, which my javascript parses as I require. I also know that php will continue to process the request even if the user closes the browser or changes pages (its all being done on the server side, so why wouldn't it? ^.^).
What I need to know:
Is the ajax handler killed when the user changes pages within my site? For example: The user is on mysite.com/foo.php. They click a link that sends off an ajax request to my server. The response of that request is to be shown in div#resp on foo.php. They then navigate to mysite.com/bar.php before the response is received.
If I load the same javascript functions and have the needed div#resp element on bar.php, can the javascript function that called the ajax still receive the response from the server and pass it into the div#resp on bar.php, thus showing the response? Or is the original ajax handle no longer available? And if it is no longer available in standard javascript, is there some implantation in jQuery that will allow me retrieve the response and show it on bar.php?
Share Improve this question edited Aug 6, 2018 at 12:40 Cœur 38.7k26 gold badges202 silver badges277 bronze badges asked Oct 6, 2012 at 1:59 Cameron OakenleafCameron Oakenleaf 1852 silver badges8 bronze badges 2 |9 Answers
Reset to default 7From what you're describing, no - once you navigate to another page and cause a page reload, all of your javascript handlers are re-instantiated and the original ones destroyed.
The answer is no. When you change page, the javascript process is killed and restarted. Nothing stays between page reload.
Although, if your page also change in ajax, then the process isn't killed, and you could receive the response. (BTW, this could be made mostly seamless to the final user with PushState
in recent browser)
No, you are not guaranteed to have your XHR (AJAX) response back before the user navigates away to the next page.
If you want to be able to detect, server-side, when a user leaves your page, you would have to use WebSocket's or a similar technology. A WebSocket connection is a long-running connection to a foreign host which you can easily detect server-side when it is severed. https://github.com/sockjs is an example of a WebSocket client + server.
If you simply want to display something to the user before he/she navigates away from the page you need to look at window.onbeforeunload - onbeforeunload fires before the user leaves the page, but will not allow you to do any async AJAX requests. For more info see https://developer.mozilla.org/en-US/docs/Web/API/window.onbeforeunload
If you want to do this, build a "single page web app". Plain and simple, do not locate to a new url.
Instead, use pushstate/popstate to change the address in the browser, and then use javascript / dynamic html to redraw the page.
You can then handle all ajax responses.
Another option is to have an onload event which fires an ajax request to the server and asks if something needs to be done. The server would need to keep track of "things" and let the browser know what's up.
Essentially the browser will poll the server at the start of each page.
I don't think a code example is necessary or applicable because it would vary for each application.
You could save the values to localStorage as you receive them, or you could save all ajax data responses in your session, memcache or redis. This means if the server receives a request then it first saves the response somewhere before returning it back. Removing the message/response from a list will depend on your situation. Some systems let you close notifications others disappear after the first time a user sees them. The disappearing one is volatile. The user may or may not actually see it.
It sounds like a "flash message" from various libraries. You may want to look at the implementation of those systems.
While the original accepted response is correct - you can't receive a response to ajax request once you navigate to a different page - there is a workaround: If you make the website a single page app you will be able to get the response.
I had the same situation on one of my projects. To have something transient between pages you HAVE to have something you recognize from one page to another. The simplest thing to use is PHP sessions (I saw you use PHP). Easy enough, you can have on each page load an Async Request (Ajax) that will check on the server (using PHPSESSID) if there is an activity started. You have the option to check on each page load (on docready) or with an interval.
Of course, you lose everything if the user closes the browser tab(s).
AS SOON AS YOU LEAVE A PAGE ALL AJAX CALLS WILL NOT BE AVAILABLE TO THE PAGE IF IT IS USED BY SIMPLE HTTP POST
The life-cycle of an HTTP request commonly looks like this:
A user visits the URL of a website. This creates a request which is routed to a web server via the internet (a network of DNS’s, routers and switches) over HTTP (Hypertext Transfer Protocol). The web server receives the HTTP request and responds to the user with the web page (or content) which was requested. Every time you click on a link and visit a web page, behind the scenes you are making a request, and in turn receiving a response from a web server. Note that HTTP requests can be made via many channels, not just web browsers. For example, an HTTP request could be made using TELNET, or a client written in JAVA or C# etc.
So you have to use sockets for this so that lifecycle of http can be tweaked.
http://devhub.fm/http-requestresponse-basics/
web socket
as thehttpd thread
that handled that ajax responsehas been closed.
This is why we use things likesocket.io
andnode.js
. – Ohgodwhy Commented Oct 6, 2012 at 2:02