|What sort of things can RUIN your AJAX?|
Ajax app is not working fine, no code changes here.
| 9:20 pm on Oct 7, 2013 (gmt 0)|
I'm going nuts here. I have a very important APP running a lot of things on AJAX and out of nowhere some things stopped working (saving data), please keep this in mind: not a single line of code has been changed regarding the data saving script. The biggest problem is: some modules do save data and some others won't. I'm going crazy here.
#1. The pages sending data to the ajax and then to the perl scripts are located at the same level, the data saving script is the same for all the modules, they just send the data. No problems of not locating the url.
#2. What fails, fails 100% of times, it's not random. Let's say pages saving "widget history" don't save while the pages managing the "widget quantities" do save. Why? I don't know.
#3. I just added some lines to one of the scripts not saving data. I verified the URL being called via AJAX and everytime this script runs, it will create a temp file. Well, it does it the first time, but not the second time (so it displays the data but won't save it). The problem is even worse to diagnose than it seems because the scripts IS ACTUALLY CALLED only one time, the rest of times it's not even reached. YES, SAME URL. Makes no sense.
#4. It worked just fine a month ago.
#5. I have the same code on another server, no problems.
#6. One PHP receives data from PERL via Query string with coordinates and data, so it can draw a PDF, it worked but it also stopped working. I sent all the same data via query string and I can read it but nothing happens, it's as if the query string had some weird characters. Already performed char cleaning there and nothing. I ended sending a short query string (10 chars) with the ID of a temp file with the original data.
Sounds to me as some sort of problem with htaccess. My htaccess is THE SAME as usual, everything worked fine! I changed nothing, something changed on the server side (config) any clues? yes I know it sounds a lost battle... I will stay on my other server but would like to know a bit more, who knows, others might "install" what these folks installed.
Thanks in advance.
| 9:25 pm on Oct 7, 2013 (gmt 0)|
Another weird thing (server side), there was a script working fine (that also stopped working) and there was no way to "fix it" because everything was fine. So by trial and error I added an extra "print content" and some debug data.
Well, the script worked again by just adding "print '1, 2, 3, 4'" (I mean whatever text or character) BEFORE a print content line. It should have triggered an error but it didn't, instead it made everything work. It makes no sense.
| 12:55 am on Oct 8, 2013 (gmt 0)|
Possibly a caching issue. Is your AJAX request a GET or a POST? I suspect you're doing a GET (which, if you're changing data on the server, you shouldn't do... not secure). POST requests won't be cached unless there are some special headers set. You can prevent a GET request from being cached by including a unique value in each request. For example, including the time stamp in the request by doing something like:
var cacheKiller = "ck=" + (new Date()).getTime();
Then appending cacheKiller to your request so you end up with something like:
| 1:13 am on Oct 8, 2013 (gmt 0)|
Thanks Fotiman for your post.
I'm actually using Post exactly for the reasons you state, it's more secure, it's not revealed on the browser url bar and allows me longer data exchange.
I'm also using cache killer, every ajax call uses a combination of date and random numbers, still doesn't work.
Today I copied all the code from server A to server B to make sure it's the same code (I was already sure about it but still...) and makes no difference: my code works, it's the server who stopped supporting the code somehow.
| 2:01 am on Oct 8, 2013 (gmt 0)|
I'd probably take a look at what HTTP headers are coming back in the response from the server. Is the server sending back a 200 response or a 304?
| 11:32 pm on Oct 8, 2013 (gmt 0)|
| 3:53 am on Oct 9, 2013 (gmt 0)|
Fotiman: Will check.
DrDoc. Yes and no. My CMS is multi site so, some sites have new or changed information, and some have still the same information. And still I can't recreate the problem on another server, that's what makes me crazy because even migrating all the data to another server it just works and it just worked in the first one.
Confused... I'm still convinced that ending my relationship with this host provider is the solution, I'm just researching for "just in case" this happens again out of nowhere on another server (software updates? who knows)
| 8:13 pm on Oct 9, 2013 (gmt 0)|
Smells like something is forcing a (somewhat transparent) cache in-between it all.
I'd look at both ends to the packets transmitted. It they do not match up: you've got a clear case of that. Note some ISPs (notably VSAT operators) use "acceleration" technology that's totally wacko in what it does to TCP connections. I'd expect weird results there.