title: Salesforce - success handler for $.ajax call
body: <p>I have a form that I have been submitting to Salesforce with standard form submit action. By default, you can tell Salesforce to redirect you to a given URL after the POST has completed.</p>
  
  <p>I no longer wish to be redirected since I have other activities on the form page. No problem, my page is already using jQuery so I can use the handy $.ajax utility like this:</p>
  
  <pre><code>$('#wrapper').on('click', '#formsubmit', function(e) {
      e.preventDefault();
  
      var formData = $('#subForm').serialize();
      $.ajax({
        type: "POST",
        url: "https://www.salesforce.com/servlet/servlet.WebToLead?encoding=UTF-8",
        data: formData,
        success: function() {
          console.log('success!'); // or not!
        },
        error:function (xhr, ajaxOptions, thrownError){
                      console.log(xhr.status); // 0
                      console.log(thrownError); // empty
                  }
      });
  });
  </code></pre>
  
  <p>In my misguided brain, I imagined that Salesforce would return my good ol' redirect, which would count as a "success" that I can just discard/ignore. Misguided indeed!</p>
  
  <ul>
  <li>I can see a 200 OK result (which usually means "success") but the success callback isn't tripped.</li>
  <li>The lead <em>is</em> added to the Salesforce database</li>
  <li>Inspecting the content of what's returned shows zero; there is no content in the response.</li>
  <li>The error callback <em>IS</em> being tripped (despite the 200 OK) but maybe due to  intentionally not redirecting it is seen as a "resource not available"? (therefore my status code is 0, and there is no content in the thrownError?).</li>
  </ul>
  
  <p>Any advice on identifying this as a successful POST so that I can trigger additional actions in a callback? I don't want to TOTALLY ignore the response, or I could end up in a scenario in which I'm acting on a failed POST as if it was successful. I need to capture the success somehow.</p>
  
  <p>It occurred to me that it could be a cross-site scripting issue as well, but since the application doesn't exchange data in JSONP, I'm not sure how to get around that (and I'm not sure how to identify it in the first place).</p>