I have a happy javascript based client that talks to my Django server-side code. I use several XMLHttpRequests for interactions and everything is fine there. Now there is one user interaction where I'd like to receive user-sent info at the server, but I don't need/want a response.
As I understand Django all views MUST respond with an HttpResponse item. I can send back a blank one, or a HttpResponseNotModified response. But anything I receive back seems to prompt the browser side to change to a blank screen.
I don't want to change pages, reload or anything. Just leave the browser session alone. I don't need a confirmation, and don't mind if some of the POST sends are even lost among a large population of responses.
I COULD do an XMLHttpResponse and catch the response and ignore it. But I'm wondering if there is any way around that.
You should return a Http204/No Content, which tells the browser that your server acknowledged and processed your request but it didn't return anything and handle that appropriately in your application (however you want to).
If you're using jQuery (for example), then this will automatically go to your success handler, and if you have no control over that, you've done the best you could.
Read the full list of status codes here
Related
I'm not an english native speaker, I'm sorry if what I say make you confused. Thanks.
I'm crawing something from a website recently.The normal operation steps should be as follows:
I log on to this website
I jump to a subpage
I click a button (actually it executes a JS function)
The website return something
But this is inconvenient, because I always need to open the browser to complete these steps. So I found the XHR of step3 in F12 and copied it to a curl command to loop through.
This is much simpler than before, but I still need to log in with a broswer and copy the latest cookie to update my curl command.
Supposing that Step1 and Step3 are actually XHRs, and I know what the args mean.
My question is, how can I get the latest cookies without using a browser, I mean, a real browser software (which I think is the only problem to be solved)? Or is there anything else I don't know that needs to be done?
A typical login consists of a post-request that is sent to the server. The payload typically contains the username and password in plain text like it was sent from a html-form. The answer from the server then contains the session-cookie (sometimes called PHPSESSID or similar) in its header.
The session-cookie can then be used to place further requests.
Sometimes the session-cookie is already set before you login, but only becomes active upon logging in. Generally you will get a new session-cookie every time you connect.
Some websites deploy technologies like google-nocaptcha-recaptcha that prevent bots from logging in at all, just so you know.
I want to send a request (or any response or notification) from the server side to the browser without a browser request to the server.
I use JSP and the Struts framework in my Java EE application. When some one is on my page, and when some processing in done in my action class/servlets, I want to send a notification or message or request to the browser to be appeared on the page. Here the relevant page cannot be refreshed or reloaded and it may be handled on the browser side with javascript or jquery. I use Http.
Is there a way to do this?
EDIT: Example: The application is an online inventory system. An Admin has logged in. If one of the items is out of stock, the admin should be notified saying that that particular item is out of stock without the admin searching the stores and do nothing (when he is on his account page, a pop up may be displayed to him).
I am not so sure what you meant but according to my understanding you can do this.I guess Comet is the thing you are looking for.Comet is the technique where in server pushes the data to the browser.
Try Pushlet concept which might address your requirement
http://www.javaworld.com/jw-03-2000/jw-03-pushlet.html
I want force users to first click on some links and then go to a specific address. How can I terminate traffic sources that are direct in the second page? Or is there any way to only accept requests that are from specific a url?
Note: if there is something wrong, I want the page not to be viewable.
Thank you
What you could do is use the document.referrer property, and check weather or not the url matches the first page. Something like this, perhaps:
if (document.referrer !== 'http://www.google.com')
{
window.location.href = 'http://www.google.com';//redirect to first url
}
As Bergi pointed out in his answer: this kind of functionality is really better left to the server side. Though suggesting cookies is, as far as I'm concerned, not the ideal way of doing this, since cookies can be turned off client side, or WCS, tempered with.
Depending on which server side technology you're using, it might pay off to read up on all tools you have at your disposal to play with the request the user sends to your application, and take appropriate actions accordingly.
You should set a cookie in the first page that the user is allowed to view the second one.
Then your serverside application would check the cookies before delivering the second page, and otherwise redirect or show an error message.
You should not do such things via JavaScript (which includes the jQuery library), elsewhile everybody who disables JS could view the page.
We have a POST to a PL/SQL database procedure that (a) does some database operations based on the POST parameters and (b) redirects the user to a page showing the results.
The problem is, when the user does a browser "refresh" of the results page, that still has the original request, so it calls the database procedure and resends the parameters.
There are things we can do with saving state so bad things don't happen if the request gets sent in again. But that got me wondering.
Is there a way to tell the browser to set the url to the redirect call, not the original user request? This would probably be in either the redirect itself, or in Javascript on the target page.
You don't mention what you are using to serve the page, but make sure you perform an EXTERNAL redirect. Some platforms will internally redirect within a site.
For instance, with Apache HTTP Server, you need to specify the force-redirect flag in mod_rewrite: http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html#RewriteRule
The 4th response here has a decent explanation of this as well.
The canonical solution is described pretty well on Wikipedia. See Post/Redirect/Get. You want the code that's handling the POST to redirect to a GET when it's work is done, as refreshing a GET will not resubmit form data.
I have an ExtJS grid on a web page and I'd like to save some of its state information back to the server when the users leaves the page.
Can I do this with an Ajax request onUnload?
If not, what's a better solution?
You can use an Ajax request, but be sure to make it a synchronous request rather than an asychronous one. Alternatively, simply save state whenever the user makes a change, this also protects the data if the user's browser crashes.
There's an answer above that says to use a synchronous ajax call, and that is the best case scenario. The problem is that unload doesn't work everywhere. If you look here you'll find some tricks to help you get unload events in safari... You could also use Google Gears to save content user side for situations where the user will be coming back, but the only fully safe way to keep that information is to continuously send it as long as the user is on the page or making changes.
You could also set a cookie using javascript on unload. I think the advantage ajax has over cookies is that you have the data available to you for reporting and the user (if logged in) can utilise the data across different machines.
The disadvantage of using ajax is that it might slow down the actual closing of the browser window, which could be annoying if the server is slow to respond.
It depends on how the user leaves the page.
If there is a 'logoff' button in your GUI, you can trigger an ajax request when the user clicks on this button.
Otherwise I do not think it is a good idea to make a request in the onUnload. As said earlier you would have to make a synchronous request...
An alternative to the cookie solution would be an hidden text field. This is a technique usually used by tools such as RSH that deal with history issues that come with ajax.