My web server can change its IP in response to a specific HTTP request.
The thing is, that the browser uses synchronic $.ajax() to post this request. Since the server IP is changed the request is aborted once timed-out ("Aborted" in firebug net tab). However, since the post is synchronic, the browser (FF in this case) hangs infinitely. As far as I understand, it is not possible to timeout or programmatically abort sync AJAX.
For many practical reasons, I cant change the request to be async. Any ideas how to handle this situation? Thanks
You have a couple options available to you.
Change server-side behavior
Change the web application on the server to complete its response to the client before changing its IP address. Then, your application gets a response whether or not the call succeeded.
Use async AJAX calls
Self-explanatory. You don't want to do this, but you really should, and not for just the problem you're having now. If your application really requires significant changes for this to work, then it probably has other design issues that could be revisited as well.
You're using a fire-and-forget method anyway currently, so I really don't see why this would be a problem.
Related
I'm working on google chrome extension which get the page url and analyze it. How can i intercept the browser request and serve that request condionally based on some criteria. I'm surfing but could find any material.
That's going to be very tricky, if at all possible.
The closest that extensions API provide is blocking webRequest API. There, you can intercept a request and make a decision to allow it or block it, but..
You can only do that until the request is sent out. So you can only rely on the URL and maybe request headers. Even in later events (when it's too late to redirect) no point webRequest API gives access to the response itself.
You have to make the decision synchronously, which basically severely limits processing options.
What you could do (very much in theory) is always redirect the request to your own "loading" page, meanwhile trying to replicate the request yourself (near-impossible to fully do, also consider side-effects), analyze the response and then substitute the "loading" page with the real one.
It's going to be either very complicated or impossible to do in complex cases. You're basically trying to implement an intercepting proxy in a Chrome extension - it doesn't really provide the full toolset to do so.
I am implementing part of a large javascript application where various scripts will be doing AJAX requests, often simultaneously.
I am considering implementing some helper class which can prioritize a stream of AJAX requests, and in some cases optimize by using a bulk api that the server understands instead of many small requests.
However I have a dilemma: if I just call e.g. jquery.ajax(), then I don't know if the request will be sent straight away, or be throttled by the browser (there may be requests executing and waiting for response already, sent from other components of the app). So, I don't really know when to do the bunching optimization, and when to just send a request straight away.
Is there a good way to ask the browser whether I'm going to be throttled in advance of issuing an AJAX request?
Our web server uses CAS for single sign on. The CAS server is running the JASIG CAS server on https://portal.ourdomain.com and the web server is running Rails on http://service.ourdomain.com.
The Rails server has its session timeout set fairly low as a single sign-out backup measure and for other reasons. So occasionally, users do get redirected to portal.ourdomain.com for reauthentication. Normally this is seamless since portal.ourdomain.com immediately redirects them back to service.ourdomain.com with an updated ticket cookie unless the CAS session has expired.
However, this doesn't work for AJAX. Web browsers do not follow redirects for XHR requests, even if the domain is the same.
One obvious solution would be to serve everything from https://ourdomain.com and stop with the subdomain nonsense. This is an extensive operation and would require serving everything through https.
Another solution would be to regularly ping the server so that it never times out. Besides the increased load on the server, having pages that never time out defeats the purpose of having the timeout in the first place.
Which leads to the third, crappy solution: just remove the timeout.
How to Overcome Cross-domain Issues for Ajax Calls to CAS-protected Resources? is a similar question which is unanswered, but that question appears to be broader, so I hope there's an answer to our question.
Does anybody have any solutions to this problem that don't suck?
You only can wrap the ajax xhr requestwhendoing revalidation, so that the browser can understand the redirect. That would need to change code for the cas proxy.
This "work around must be checked and extended (in worst case) for every kind of ajax web framework. We did it for jquery, which gladly is ajax base for rails3.
After reading this post (probably, you can get the gist by looking at the images, no need to read the whole text), I'm having a hard time deciding at which point is needed the help of comet type technologies.
It looks to me (naively) that all of that can be accomplished by using ajax requests and a database to retrieve several versions. Is that true?.
Probably I'm missing something, so a clarification would be great.
UPDATE:
Given the helpful answer written by Andrew, saying that an ajax approach to this issue it is not timely, I was wondering why, that is, at which stage the response sent by the server to the client will produce a delay?.
Comet IS Ajax requests.
In order for the server to be able to push notifications to the users browsers(IE anytime you see the server sending a change in the diagrams), the user needs to have a connection with the server already. The method of maintaining that connection using ajax long polling or the like is what the term comet refers to.
Yes, you could implement this by sending an Ajax request every x seconds. But that is wasteful, and it is not timely.
[Edit]
When I say it's not timely, what I am saying is that, using an ajax call to update on an interval will have a delay of whatever that interval is.
The server CANNOT send an update to the client. It can only answer requests from the client. So if the server gets new information, it has to sit on it until all the clients come back and ask for an update. In a scenario like this people can edit the same information and commit it at the same time, which needs to be handled by the server, and which is what the article is addressing. Using a comet framework will just reduce the chances of this happening because the different clients will be better synced.
I am working around AJAX for few months now and i see Ajax request as following,
Pass parameters to background page (PHP/ASP/HTML/TXT/XML ... what else can be here?)
Do some processing on server
Get back the results and show to client (HTML/XML/JSON ... what else can be here?)
If there is something else to add on Request lifecycle please I will be glad to know?
Now I have some questions around AJAX and i will try to frame them one by one.
How many concurrent AJAX request can be made?
Yes there is timeout period in AJAX but considering the web2.0 scenarios and possibilities with the Network what is the timeout period? Best practice?
Consider scenario that if user invoke AJAX Request and it’s in process on the server and meanwhile user left the page. Will the processing on the server will be left in haft way? Or all the execution on server will be done and response is sent back to browser? What will happen?
Is it a strict requirement that we should have a server page (PHP/JSP/ASP) to take the AJAX request? As with this approach considering wide use of AJAX now a day, on server we need page per request (or few pages to server more than one request) which is something become difficult to maintain.
Can we have something else instead of server side page (PHP/ASP etc.) like web service or something which can be directly requested from AJAX (JavaScript) like URL? If yes how? This can reduce need of additional server side pages.
AJAX request also supports the Authentication. In what scenario this is used? Is it mandatory?
Comet is something which I heard lot about. My understanding is that it’s just some pattern in which AJAX is used to get updated data by using polling mechanism. Is it right? Please provide your views/insight.
Security risk using AJAX? How can it can be mitigated (Encryption/Decryption or something else)?
Thanks all,
Depends on the browser. It follows the same rules as concurrent HTTP requests everywhere else in the browser.
Ditto.
Pretty much the same as the user hitting the Stop button on a regular page.
An HTTP request must request a URI. How you handle that on the backend is up to you. The term "page" doesn't really fit — that is an HTML document with associated resources (stylesheets, images, etc). Most systems don't have a 1:1 mapping between server side programs and resources. In an MVC pattern, for example, it isn't uncommon to have a shared model and a controller that just switches between views for determining if to return an HTML document or the same data expressed in JSON.
A web service is just a server side program that responds in a particular way, lots of people write them using PHP, JSP or ASP so the question doesn't really make sense.
No, it isn't mandatory. You use authentication when you need authentication. There is no special "ajax authentication", that is usually just using the same cookies that are used everywhere else in the site.
No, the point of Comet is to avoid polling. See http://en.wikipedia.org/wiki/Comet_%28programming%29
Requests containing data are sent to the server. Responses containing data are returned from the server. The security implications are no different to any other HTTP request you handle.
You must use the URI to use it