I am trying to make sure my client-side code does not send another request before it receives a reply. To the best of my knowledge the code I will post is supposed to do this but I am still getting a -1 for $return.

The AJAX request repeatedly gets the echoed value of a function which is using a batch file to get the size of a file that is being uploaded via FTP. The application using this shifted storage and is now in UNC path and now the AJAX gets nothing in return.

If I run the bat file manually I can get a response, but it might take 1 second or it might take a minute, for some reason there doesn't seem to be a lot in the middle. If I use the PHP script to call it I get $out equal to an empty array and $return equal to -1. My guess is that it's taking so long to process the request the Ajax requests are interrupting each other.


I am using ajaxTime to try and see how long the requests are taking. They are varying from usually around 550-650 response time:

var ajaxTime = new Date().getTime();
getdSize(f, ajaxTime);

function getSize(f, ajaxTime){
            url: "php file handling the ajax request",
            type: "POST",
            data: {
                file : encodeURIComponent(f),
            var totalTime = new Date().getTime()-ajaxTime;
            console.log("Ajax Time: " + totalTime);
            console.log("Data: " + data);
            if ( data.responseCode ){
              console.log( data.responseCode );
            console.log("Ajax failure");


    $file = $_POST['file'];
    echo bat_getSize($file);
[this calls bat_getSize function]

function bat_getSize($file){
    exec("getSize \"$file\"",$out, $ret);
    return $out[0];

Which calls this batch code:

@echo off
echo %~z1

1 Answer 1


To be sure that nothing happens before the AJAX request is achieved, you can simply add the async: false property to your $.ajax({...}).

As pointed by @Tom Stickel, doing so fires a warning about future deprecation of async: false.

I agree, and this is already known from times but, as stated in paragraph 4.5.1 of the page he cited:

This is a long process that takes many years

It's why I suggest this solution (and also am using it somewhat frequently), but:

  1. only in the case of this kind of situation, where the "detrimental effects to the end user's experience" is clearly not involved (at the opposite, here, it's precisely what is expected)
  2. only for now, considering it's worth applying a so simple solution as long as it works, and change it only when deprecation will effectively happen (note that the involved piece of code might be obsolete first!)
  • \$\begingroup\$ Well you most likely will get this message in Chrome: Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check xhr.spec.whatwg.org. \$\endgroup\$ Commented Mar 30, 2016 at 23:09
  • \$\begingroup\$ @TomStickel Indeed it's true and I didn't ignored it, but also didn't make the effort to clearly explain why I nevertheless proposed it. Sure it was a lack in my answer: it's now filled, thanks to you. \$\endgroup\$
    – cFreed
    Commented Mar 31, 2016 at 15:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.